From fj7025cf at aa.jp.fujitsu.com Tue Apr 1 06:26:54 2008 From: fj7025cf at aa.jp.fujitsu.com (Hiroyuki Kaguchi) Date: Tue, 01 Apr 2008 15:26:54 +0900 Subject: [et-mgmt-tools] [PATCH] remove showing incorrect partition size on guest OS installation Message-ID: <47F1D5AE.8030008@aa.jp.fujitsu.com> When we install guest OS to a partition by virt-manager, the "Ready to begin installation" window shows the size of "Simple File", NOT the size of the partition. I make a patch that it displays "-" as the size of the storage-partition for this partition case. Signed-off-by: Hiroyuki Kaguchi --- diff -r 2ea7f77b0339 src/virtManager/create.py --- a/src/virtManager/create.py Fri Mar 28 13:37:27 2008 -0400 +++ b/src/virtManager/create.py Mon Mar 31 17:51:32 2008 +0900 @@ -392,6 +392,8 @@ class vmmCreate(gobject.GObject): return self.window.get_widget("storage-file-address").get_text() def get_config_disk_size(self): + if not self.window.get_widget("storage-file-backed").get_active(): + return None if not self.window.get_widget("storage-file-size").get_editable(): return None else: From foss.mailinglists at gmail.com Tue Apr 1 08:42:05 2008 From: foss.mailinglists at gmail.com (Sankarshan Mukhopadhyay) Date: Tue, 01 Apr 2008 14:12:05 +0530 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F15937.90906@redhat.com> References: <47F15937.90906@redhat.com> Message-ID: <47F1F55D.1030909@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael DeHaan wrote: | Possible Answer2 -- If you're not in the admin group, you can't edit | kickstart template files at all. Would users not in Admin Group require editing rights ? Or, should they be allowed to edit ? | Possible Answer3 -- Remove kickstart editing from the WebUI, and | encourage users to create kickstart templates where they have filesystem | access (i..e their home directories) Possibly the best option if the answer is Yes to above. | Answer? I think the answer is Subprofile B is promoted to a full | profile with all of the inherited fields set to the values of Profile A. | However this is complicated and confusing so "No deletion allowed" may | be the better route. No deletion allowed seems saner. | Any thoughts on the above from those who have a vested interest in | controlling access to cobbler objects through the WebUI? i don't have a vested interest yet ;) but would sure be watching the responses to these interesting questions - -- http://www.gutenberg.net - Fine literature digitally re-published http://www.plos.org - Public Library of Science http://www.creativecommons.org - Flexible copyright for creative work -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH8fVdXQZpNTcrCzMRAqJQAKCien3eJsMFO14ZehgmoDj4oJeyjQCeLHn1 OwUSw1UEw1fPkfA0xJXtI44= =oESY -----END PGP SIGNATURE----- From bkearney at redhat.com Tue Apr 1 12:39:43 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 01 Apr 2008 08:39:43 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F15937.90906@redhat.com> References: <47F15937.90906@redhat.com> Message-ID: <47F22D0F.6080405@redhat.com> Michael DeHaan wrote: > So, > > Warning -- technical email :) > > I have a pretty good ownership module going for Cobbler now > (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), that > allows you to say that objects are owned by certain users and/or groups, > and prevents users not in those groups (except for an admin group) to be > able to edit those objects. This is designed for very large > organizations that may want lab admins to control certain profiles, but > not all of them (for instance, a build lab versus a test lab versus a > production datacenter, etc). > In this implementation, users in the admin group have access to all > objects always, and by default all objects are created with no editing > restrictions unless the creator decides to lock them down. The > command line has none of these restrictions so you can always > recover/reconfigure things with root if you find you've somehow locked > yourself out. (It's also coded up so you can't use the WebUI to remove > your own access from an object). > > There are a couple of policy questions for this dealing with some of the > corner cases. > > (A) What to do about kickstart editing in the WebUI. This is the "fun" > corner case to figure out. > > The WebUI contains a very basic kickstart template editor (it's just a > text field for now). > Possible Answer1? I think the solution is that a kickstart template file > can be edited if the user editing it is allowed to edit ALL > profiles/systems making use of it. This is a bit of a catch 22 as it > would be possible to create a system using a template file, just for the > purpose of making that user not be able to edit it. This shouldn't > happen but is technically possible. > Possible Answer2 -- If you're not in the admin group, you can't edit > kickstart template files at all. > > Possible Answer3 -- Remove kickstart editing from the WebUI, and > encourage users to create kickstart templates where they have filesystem > access (i..e their home directories) For testing, I have liked the ability to edit he ks file and not need to log into the box. If possible, please keep it. It may be heinous, but is there a model where each ks has a security item associated to it (e.g. a role) or ks files can be grouped and a role associated to the group? > > ---- > > (B) What do to about "orphanage". > > If UserA owns ProfileA, and UserB owns SystemB, which depends on > ProfileB, what happens if UserA wants to delete ProfileA? > > Answer? The profile cannot be deleted. > > If UserA owns ProfileA, and UserB owns SubprofileB, what happens when > UserA wants to delete ProfileA? > > Answer? I think the answer is Subprofile B is promoted to a full > profile with all of the inherited fields set to the values of Profile A. > However this is complicated and confusing so "No deletion allowed" may > be the better route. First cut, no delete. Every time i have used nested profiles it was becuase I had nested logic in the kickstart file. So. promoting a subprofile would cause the subprofile to break. > > --- > > (C) FYI... > > Everyone is allowed to run "cobbler sync" if they can authenticate. I > don't think this should be a problem. > > Also, if you're in, you can read everything, you just might not be able > to /write/ everything. This also should not be a problem as provisioning > data is basically public if you want to use it in a Fully Automated > Context anyway. > > Currently settings, modules.conf, and users.conf can't be edited through > the WebUI as that's a really good way to lock yourself out of the WebUI > altogether :) > > --- > > Any thoughts on the above from those who have a vested interest in > controlling access to cobbler objects through the WebUI? > Remember this is all off by default and is only there if you want it -- > but if you want it, I want to make sure this fits your organizational > needs. > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From swissslinky at gmail.com Tue Apr 1 12:53:10 2008 From: swissslinky at gmail.com (Slinky) Date: Tue, 1 Apr 2008 14:53:10 +0200 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F15937.90906@redhat.com> References: <47F15937.90906@redhat.com> Message-ID: On 31/03/2008, Michael DeHaan wrote: -slash- The command line has none of these restrictions so you can always > recover/reconfigure things with root if you find you've somehow locked > yourself out. Will this always been the case? We'd like to see the same ownership model apply to the webui and CLI. (It's also coded up so you can't use the WebUI to remove > your own access from an object). ^ see above -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Apr 1 16:05:41 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Apr 2008 12:05:41 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F1F55D.1030909@gmail.com> References: <47F15937.90906@redhat.com> <47F1F55D.1030909@gmail.com> Message-ID: <47F25D55.60603@redhat.com> Sankarshan Mukhopadhyay wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael DeHaan wrote: > > | Possible Answer2 -- If you're not in the admin group, you can't edit > | kickstart template files at all. > > Would users not in Admin Group require editing rights ? Or, should they > be allowed to edit ? Any user in an admin group would have rights to everything, automatically. > > | Possible Answer3 -- Remove kickstart editing from the WebUI, and > | encourage users to create kickstart templates where they have > filesystem > | access (i..e their home directories) > > Possibly the best option if the answer is Yes to above. > > | Answer? I think the answer is Subprofile B is promoted to a full > | profile with all of the inherited fields set to the values of > Profile A. > | However this is complicated and confusing so "No deletion allowed" may > | be the better route. > > No deletion allowed seems saner. Probably. > > > | Any thoughts on the above from those who have a vested interest in > | controlling access to cobbler objects through the WebUI? > > i don't have a vested interest yet ;) but would sure be watching the > responses to these interesting questions > Perfectly valid :) > > > > - -- > > http://www.gutenberg.net - Fine literature digitally re-published > http://www.plos.org - Public Library of Science > http://www.creativecommons.org - Flexible copyright for creative work > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFH8fVdXQZpNTcrCzMRAqJQAKCien3eJsMFO14ZehgmoDj4oJeyjQCeLHn1 > OwUSw1UEw1fPkfA0xJXtI44= > =oESY > -----END PGP SIGNATURE----- > > _______________________________________________ > 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 Apr 1 16:08:35 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Apr 2008 12:08:35 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F22D0F.6080405@redhat.com> References: <47F15937.90906@redhat.com> <47F22D0F.6080405@redhat.com> Message-ID: <47F25E03.40102@redhat.com> Bryan Kearney wrote: > > > Michael DeHaan wrote: >> So, >> >> Warning -- technical email :) >> >> I have a pretty good ownership module going for Cobbler now >> (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), >> that allows you to say that objects are owned by certain users and/or >> groups, and prevents users not in those groups (except for an admin >> group) to be able to edit those objects. This is designed for very >> large organizations that may want lab admins to control certain >> profiles, but not all of them (for instance, a build lab versus a >> test lab versus a production datacenter, etc). >> In this implementation, users in the admin group have access to all >> objects always, and by default all objects are created with no >> editing restrictions unless the creator decides to lock them >> down. The command line has none of these restrictions so you can >> always recover/reconfigure things with root if you find you've >> somehow locked yourself out. (It's also coded up so you can't use >> the WebUI to remove your own access from an object). >> >> There are a couple of policy questions for this dealing with some of >> the corner cases. >> >> (A) What to do about kickstart editing in the WebUI. This is the >> "fun" corner case to figure out. >> >> The WebUI contains a very basic kickstart template editor (it's just >> a text field for now). Possible Answer1? I think the solution is that >> a kickstart template file can be edited if the user editing it is >> allowed to edit ALL profiles/systems making use of it. This is a bit >> of a catch 22 as it would be possible to create a system using a >> template file, just for the purpose of making that user not be able >> to edit it. This shouldn't happen but is technically possible. >> Possible Answer2 -- If you're not in the admin group, you can't edit >> kickstart template files at all. >> >> Possible Answer3 -- Remove kickstart editing from the WebUI, and >> encourage users to create kickstart templates where they have >> filesystem access (i..e their home directories) > > For testing, I have liked the ability to edit he ks file and not need > to log into the box. If possible, please keep it. It may be heinous, > but is there a model where each ks has a security item associated to > it (e.g. a role) or ks files can be grouped and a role associated to > the group? The ownership module is off by default, so if we removed it, it might only be for that. I think we can find a workable solution though :) I'm trying to avoid creating an additional cobbler object wrapping the kickstarts -- as that ends up creating too many Cobbler objects and makes things less simpler for newer users (who have this feature turned off by default, anyway). >> >> ---- >> >> (B) What do to about "orphanage". >> >> If UserA owns ProfileA, and UserB owns SystemB, which depends on >> ProfileB, what happens if UserA wants to delete ProfileA? >> >> Answer? The profile cannot be deleted. >> >> If UserA owns ProfileA, and UserB owns SubprofileB, what happens when >> UserA wants to delete ProfileA? >> >> Answer? I think the answer is Subprofile B is promoted to a full >> profile with all of the inherited fields set to the values of Profile A. >> However this is complicated and confusing so "No deletion allowed" >> may be the better route. > > First cut, no delete. Every time i have used nested profiles it was > becuase I had nested logic in the kickstart file. So. promoting a > subprofile would cause the subprofile to break. I agree. Though it might not cause breakage if we promote the attributes that are marked "inherit", it's clearly non-obvious behavior to the user. The admin could always intervene and blow away all objects below it if required. >> >> --- >> >> (C) FYI... >> >> Everyone is allowed to run "cobbler sync" if they can authenticate. >> I don't think this should be a problem. >> >> Also, if you're in, you can read everything, you just might not be >> able to /write/ everything. This also should not be a problem as >> provisioning >> data is basically public if you want to use it in a Fully Automated >> Context anyway. >> >> Currently settings, modules.conf, and users.conf can't be edited >> through the WebUI as that's a really good way to lock yourself out of >> the WebUI >> altogether :) >> >> --- >> >> Any thoughts on the above from those who have a vested interest in >> controlling access to cobbler objects through the WebUI? >> Remember this is all off by default and is only there if you want it >> -- but if you want it, I want to make sure this fits your >> organizational needs. >> >> --Michael >> >> _______________________________________________ >> 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 From mdehaan at redhat.com Tue Apr 1 16:24:22 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Apr 2008 12:24:22 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: References: <47F15937.90906@redhat.com> Message-ID: <47F261B6.4050906@redhat.com> Slinky wrote: > > > On 31/03/2008, *Michael DeHaan* > wrote: > > > -slash- > > The command line has none of these restrictions so you can always > recover/reconfigure things with root if you find you've somehow locked > yourself out. > > > Will this always been the case? We'd like to see the same ownership > model apply to the webui and CLI. Originally I wasn't planning on adding auth to the command line. Interesting idea. You could also perhaps get away with making a simple remote command line that only contained the features you needed and used the existing XMLRPC/CobblerWeb code as a basis. It would have to accept a username and password, possibly from doing something like reading ~/.cobbler.rc or something? If it didn't have to do things like "import" it would be pretty simple. There are more complicated alternatives involving ACLs and setuid (non root), but I think I like that solution better. Thoughts? > > > (It's also coded up so you can't use the WebUI to remove > your own access from an object). > > > ^ see above > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Apr 1 16:34:31 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Apr 2008 12:34:31 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F261B6.4050906@redhat.com> References: <47F15937.90906@redhat.com> <47F261B6.4050906@redhat.com> Message-ID: <47F26417.6020000@redhat.com> Michael DeHaan wrote: > Slinky wrote: >> >> >> On 31/03/2008, *Michael DeHaan* > > wrote: >> >> >> -slash- >> >> The command line has none of these restrictions so you can always >> recover/reconfigure things with root if you find you've somehow >> locked >> yourself out. >> >> Will this always been the case? We'd like to see the same ownership >> model apply to the webui and CLI. > > Originally I wasn't planning on adding auth to the command line. > Interesting idea. > > You could also perhaps get away with making a simple remote command > line that only contained the features you needed and used the existing > XMLRPC/CobblerWeb code as a basis. It would have to accept a > username and password, possibly from doing something like reading > ~/.cobbler.rc or something? If it didn't have to do things like > "import" it would be pretty simple. > > There are more complicated alternatives involving ACLs and setuid (non > root), but I think I like that solution better. > > Thoughts? Actually the local approach may not be too bad either. We make cobbler setuid to a cobbler user (not by default, but in this configuration only), set that user up with ACLs on the right places, and turn on a flag in settings that says "require_local_auth". We make the api module in cobbler make the same calls Cobbler is using for remote if "require_local_auth" is on. And then we require user/password info when "require_local_auth" is enabled by adding some new arguments or reading a file in "~/" (or something... yes, kerberos is in the running but we must also support /non/ kerberos). Setup will not be super-trivial, but we could perhaps make a sample script to help people with that configuration. I see Dan has this use case, but does anyone else? I hesistate to add to much to support niche cases, though often these seem to be some of the things larger installs are sometimes looking for. --Michael From sys.mailing at gmail.com Tue Apr 1 18:46:47 2008 From: sys.mailing at gmail.com (Bjorn Oglefjorn) Date: Tue, 1 Apr 2008 14:46:47 -0400 Subject: [et-mgmt-tools] [Cobbler] [PATCH] Cleaning up the authn_ldap module Message-ID: <926ab61b0804011146j661542a5q5686f52df30e075f@mail.gmail.com> Issues addressed in the attached patch: - allow anonymous or bind'ed searches to obtain a user's full DN - allow for a configurable user search prefix (eg: 'uid=', 'cn=', etc...) The following items (and their proposed defaults) are needed in /var/lib/cobbler/settings to accommodate this patch: ldap_anonymous_bind: 1 ldap_search_bind_dn: '' ldap_search_passwd: '' ldap_search_prefix: 'uid=' So if your LDAP server does not allow anonymous binds, you would need to set: ldap_anonymous_bind: 0 ldap_search_bind_dn: '' ldap_search_passwd: '' Questions? See me in #cobbler. --Vito Laurenza -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: auth_ldap.py.diff.txt URL: From mdehaan at redhat.com Tue Apr 1 19:26:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 01 Apr 2008 15:26:52 -0400 Subject: [et-mgmt-tools] [Cobbler] [PATCH] Cleaning up the authn_ldap module In-Reply-To: <926ab61b0804011146j661542a5q5686f52df30e075f@mail.gmail.com> References: <926ab61b0804011146j661542a5q5686f52df30e075f@mail.gmail.com> Message-ID: <47F28C7C.20203@redhat.com> Bjorn Oglefjorn wrote: > Issues addressed in the attached patch: > - allow anonymous or bind'ed searches to obtain a user's full DN > - allow for a configurable user search prefix (eg: 'uid=', 'cn=', > etc...) > > The following items (and their proposed defaults) are needed in > /var/lib/cobbler/settings to accommodate this patch: > ldap_anonymous_bind: 1 > ldap_search_bind_dn: '' > ldap_search_passwd: '' > ldap_search_prefix: 'uid=' > > So if your LDAP server does not allow anonymous binds, you would need > to set: > ldap_anonymous_bind: 0 > ldap_search_bind_dn: > '' > ldap_search_passwd: '' > > Questions? See me in #cobbler. > > --Vito Laurenza > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Applied with some tweaks -- added the new variables to the settings file, etc. Thanks! Vito mentioned on IRC the Wiki is going to be updated with details later (https://fedorahosted.org/cobbler/wiki/CobblerWithLdap), if anyone with an LDAP config would like to test this, please do. The default values in the config file should be right for most installs (other than the basedn and server), if you need the others they will be up on the Wiki. --Michael From swissslinky at gmail.com Wed Apr 2 12:38:19 2008 From: swissslinky at gmail.com (Slinky) Date: Wed, 2 Apr 2008 14:38:19 +0200 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F26417.6020000@redhat.com> References: <47F15937.90906@redhat.com> <47F261B6.4050906@redhat.com> <47F26417.6020000@redhat.com> Message-ID: I think if we are to deploy Cobbler more, we would create something which allows remote communication to cobbler. It wouldn't care about import or such, just things like add/remove/edit objects like distros/profiles/systems/kickstarts and maybe sync. The end result would be a "cobbler client" talking to the XMLRPC interface, using kerberos5 credentials to get access (but at this point I'm not too sure how I can pass my krb credential as a blob to Cobbler for checking with kerberos. For the moment if we really need the client, we can create somehting using demo_connect and pass the approapriate credentials to ldap, via Cobbler, but in the end we would need authentication as transparent as possibe. If the setuid option comes in though, we like this a lot. It means we start to move away from cobbler running as root.... Just some mumblings after lunch. On 01/04/2008, Michael DeHaan wrote: > > Michael DeHaan wrote: > > > Slinky wrote: > > > > > > > > > > > On 31/03/2008, *Michael DeHaan* > > mdehaan at redhat.com>> wrote: > > > > > > > > > -slash- > > > > > > The command line has none of these restrictions so you can always > > > recover/reconfigure things with root if you find you've somehow > > > locked > > > yourself out. > > > Will this always been the case? We'd like to see the same ownership > > > model apply to the webui and CLI. > > > > > > > Originally I wasn't planning on adding auth to the command line. > > Interesting idea. > > > > You could also perhaps get away with making a simple remote command line > > that only contained the features you needed and used the existing > > XMLRPC/CobblerWeb code as a basis. It would have to accept a username and > > password, possibly from doing something like reading ~/.cobbler.rc or > > something? If it didn't have to do things like "import" it would be pretty > > simple. > > > > There are more complicated alternatives involving ACLs and setuid (non > > root), but I think I like that solution better. > > > > Thoughts? > > > > Actually the local approach may not be too bad either. > > We make cobbler setuid to a cobbler user (not by default, but in this > configuration only), set that user up with ACLs on the right places, and > turn on a flag in settings that says "require_local_auth". We make the api > module in cobbler make the same calls Cobbler is using for remote if > "require_local_auth" is on. And then we require user/password info when > "require_local_auth" is enabled by adding some new arguments or reading a > file in "~/" (or something... yes, kerberos is in the running but we must > also support /non/ kerberos). > Setup will not be super-trivial, but we could perhaps make a sample script > to help people with that configuration. > I see Dan has this use case, but does anyone else? I hesistate to add to > much to support niche cases, though often these seem to be some of the > things larger installs are sometimes looking for. > > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Regards Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Apr 2 14:54:50 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 Apr 2008 10:54:50 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: References: <47F15937.90906@redhat.com> <47F261B6.4050906@redhat.com> <47F26417.6020000@redhat.com> Message-ID: <47F39E3A.2000700@redhat.com> > > If the setuid option comes in though, we like this a lot. It means we > start to move away from cobbler running as root.... Here's a third simpler design option for a non-root command line that may not require remoting... I'm a big fan of letting the OS do the work when possible so this may be a good idea. -- Set up ACLs for users that need to get access to cobbler data. We can come up with a script to do this. -- Do not set cobbler up as setuid/anything, have it run as whatever user runs it -- Have the cobbler binary ask the OS for the logged in uid/username, and use authorization rules based on that (such as ownership). -- In this case, the OS could use whatever facility it wants for authentication of user accounts. We still need to kerberize the web services though for those who aren't satisfied with the LDAP method, but this allows you to have ownership and multiple users getting at the cobbler command line as non-root, and you could choose your OS authentication mechanism to be anything you want (including kerb/LDAP/NIS). Make sense? This would be relatively simple, and since the default authorization policy is "allow all", it works out of the box without the user having to configure anything. The command line can easily check to see if the user has access to the files in question and would report if ACL's are not set up right. Should be pretty close to what we want... --Michael > > > On 01/04/2008, *Michael DeHaan* > wrote: > > Michael DeHaan wrote: > > Slinky wrote: > > > > On 31/03/2008, *Michael DeHaan* >> wrote: > > > -slash- > > The command line has none of these restrictions so you > can always > recover/reconfigure things with root if you find you've > somehow locked > yourself out. > Will this always been the case? We'd like to see the same > ownership model apply to the webui and CLI. > > > Originally I wasn't planning on adding auth to the command > line. Interesting idea. > > You could also perhaps get away with making a simple remote > command line that only contained the features you needed and > used the existing XMLRPC/CobblerWeb code as a basis. It > would have to accept a username and password, possibly from > doing something like reading ~/.cobbler.rc or something? If > it didn't have to do things like "import" it would be pretty > simple. > > There are more complicated alternatives involving ACLs and > setuid (non root), but I think I like that solution better. > > Thoughts? > > > Actually the local approach may not be too bad either. > > We make cobbler setuid to a cobbler user (not by default, but in > this configuration only), set that user up with ACLs on the right > places, and turn on a flag in settings that says > "require_local_auth". We make the api module in cobbler make the > same calls Cobbler is using for remote if "require_local_auth" is > on. And then we require user/password info when > "require_local_auth" is enabled by adding some new arguments or > reading a file in "~/" (or something... yes, kerberos is in the > running but we must also support /non/ kerberos). > Setup will not be super-trivial, but we could perhaps make a > sample script to help people with that configuration. > I see Dan has this use case, but does anyone else? I hesistate > to add to much to support niche cases, though often these seem to > be some of the things larger installs are sometimes looking for. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > -- > Regards > Dan > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Wed Apr 2 19:11:16 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 20:11:16 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update Message-ID: <47F3DA54.5090007@ng23.net> Hi i use cobbler to configure my repo's with cobbler repo add etc and this works fine. Can anyone give me any pointers to the process of adding a new rpm to a repo and syncing it so its available using yum, all through the use of cobbler? thanks From mdehaan at redhat.com Wed Apr 2 19:25:36 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 Apr 2008 15:25:36 -0400 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3DA54.5090007@ng23.net> References: <47F3DA54.5090007@ng23.net> Message-ID: <47F3DDB0.3000606@redhat.com> Tom Brown wrote: > Hi > > i use cobbler to configure my repo's with cobbler repo add etc and > this works fine. Can anyone give me any pointers to the process of > adding a new rpm to a repo and syncing it so its available using yum, > all through the use of cobbler? > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools If you want to maintain your own repo with rpms, all you have to do is ... mkdir /opt/foo cp /opt/foo cobbler repo add --name=foo-name --mirror=/opt/foo (this actually uses rsync, so if you have another box in your org, with a directory full of RPMs, you can pass in --mirror=user at server:/opt/foo) And it will take care of calling createrepo and making sure the repo config files are all created correctly. I'd recommend doing that rather than trying to add an RPM to an existing mirrored repo, as that will make it clearer what comes from where and you can enable/disable individual repos as needed. --Michael From tom at ng23.net Wed Apr 2 19:33:43 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 20:33:43 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3DDB0.3000606@redhat.com> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> Message-ID: <47F3DF97.4090307@ng23.net> > > If you want to maintain your own repo with rpms, all you have to do is > ... > > mkdir /opt/foo > cp /opt/foo > cobbler repo add --name=foo-name --mirror=/opt/foo > (this actually uses rsync, so if you have another box in your org, > with a directory full of RPMs, you can pass in > --mirror=user at server:/opt/foo) > > And it will take care of calling createrepo and making sure the repo > config files are all created correctly. > > I'd recommend doing that rather than trying to add an RPM to an > existing mirrored repo, as that will make it clearer what comes from > where and you can enable/disable individual repos as needed. > thanks - i will bear this in mind - for this scenario i just added that rpm to a current repo - ram createrepo on it and then cobbler reposync and thats now available in the repo cobbler is aware of. I will add and remove rpm's from existing repo's quite a lot so creating a repo each time would be a bit of a pain to manage. thanks From mdehaan at redhat.com Wed Apr 2 19:48:07 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 Apr 2008 15:48:07 -0400 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3DF97.4090307@ng23.net> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F3DF97.4090307@ng23.net> Message-ID: <47F3E2F7.7020206@redhat.com> Tom Brown wrote: > >> >> If you want to maintain your own repo with rpms, all you have to do >> is ... >> >> mkdir /opt/foo >> cp /opt/foo >> cobbler repo add --name=foo-name --mirror=/opt/foo >> (this actually uses rsync, so if you have another box in your org, >> with a directory full of RPMs, you can pass in >> --mirror=user at server:/opt/foo) >> >> And it will take care of calling createrepo and making sure the repo >> config files are all created correctly. >> >> I'd recommend doing that rather than trying to add an RPM to an >> existing mirrored repo, as that will make it clearer what comes from >> where and you can enable/disable individual repos as needed. >> > > thanks - i will bear this in mind - for this scenario i just added > that rpm to a current repo - ram createrepo on it and then cobbler > reposync and thats now available in the repo cobbler is aware of. I > will add and remove rpm's from existing repo's quite a lot so creating > a repo each time would be a bit of a pain to manage. Right, use the above trick and it will be dealt with automatically, if you add it to an existing one, reposync will undo your changes each time you update. > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From tom at ng23.net Wed Apr 2 20:02:18 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 21:02:18 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3E2F7.7020206@redhat.com> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F3DF97.4090307@ng23.net> <47F3E2F7.7020206@redhat.com> Message-ID: <47F3E64A.3000707@ng23.net> > > Right, use the above trick and it will be dealt with automatically, if > you add it to an existing one, reposync will undo your changes each > time you update. > hmmm i did cp rpm to /repo/foo/1 (/repo/foo/1 was the resultant dir of a cobbler repo add) createrepo /repo/foo/1 cobbler reposync the result of this was that the rpm was now present and available to install using yum from /repo/foo/1 so it seems to work - From mdehaan at redhat.com Wed Apr 2 20:05:55 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 Apr 2008 16:05:55 -0400 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3E64A.3000707@ng23.net> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F3DF97.4090307@ng23.net> <47F3E2F7.7020206@redhat.com> <47F3E64A.3000707@ng23.net> Message-ID: <47F3E723.1060703@redhat.com> Tom Brown wrote: > >> >> Right, use the above trick and it will be dealt with automatically, >> if you add it to an existing one, reposync will undo your changes >> each time you update. >> > > hmmm i did > > cp rpm to /repo/foo/1 (/repo/foo/1 was the resultant dir of a cobbler > repo add) > createrepo /repo/foo/1 > cobbler reposync If the cobbler repo directory is already mirrored you do not need to run createrepo again. cobbler reposync will do that for you. From tom at ng23.net Wed Apr 2 21:16:44 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 22:16:44 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3E723.1060703@redhat.com> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F3DF97.4090307@ng23.net> <47F3E2F7.7020206@redhat.com> <47F3E64A.3000707@ng23.net> <47F3E723.1060703@redhat.com> Message-ID: <47F3F7BC.7070206@ng23.net> > > If the cobbler repo directory is already mirrored you do not need to run > createrepo again. > cobbler reposync will do that for you. ok thanks - i'll give it a shot From tom at ng23.net Wed Apr 2 21:53:33 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 22:53:33 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F3DDB0.3000606@redhat.com> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> Message-ID: <47F4005D.1040700@ng23.net> > > If you want to maintain your own repo with rpms, all you have to do is > ... > > mkdir /opt/foo > cp /opt/foo > cobbler repo add --name=foo-name --mirror=/opt/foo > (this actually uses rsync, so if you have another box in your org, > with a directory full of RPMs, you can pass in > --mirror=user at server:/opt/foo) > > And it will take care of calling createrepo and making sure the repo > config files are all created correctly. > > I'd recommend doing that rather than trying to add an RPM to an > existing mirrored repo, as that will make it clearer what comes from > where and you can enable/disable individual repos as needed. > [root at cobbler-server noarch]# mkdir /opt/foo [root at cobbler-server noarch]# cp *rpm /opt/foo/ [root at cobbler-server noarch]# cobbler repo add --name=testing-extras --mirror=/opt/foo [root at cobbler-server noarch]# ll /opt/foo/*rpm | wc -l 19 [root at cobbler-server noarch]# something is not right there - just fails silently ? From mdehaan at redhat.com Wed Apr 2 21:55:13 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 02 Apr 2008 17:55:13 -0400 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F4005D.1040700@ng23.net> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F4005D.1040700@ng23.net> Message-ID: <47F400C1.7050004@redhat.com> Tom Brown wrote: > >> >> If you want to maintain your own repo with rpms, all you have to do >> is ... >> >> mkdir /opt/foo >> cp /opt/foo >> cobbler repo add --name=foo-name --mirror=/opt/foo >> (this actually uses rsync, so if you have another box in your org, >> with a directory full of RPMs, you can pass in >> --mirror=user at server:/opt/foo) >> >> And it will take care of calling createrepo and making sure the repo >> config files are all created correctly. >> >> I'd recommend doing that rather than trying to add an RPM to an >> existing mirrored repo, as that will make it clearer what comes from >> where and you can enable/disable individual repos as needed. >> > > [root at cobbler-server noarch]# mkdir /opt/foo > [root at cobbler-server noarch]# cp *rpm /opt/foo/ > [root at cobbler-server noarch]# cobbler repo add --name=testing-extras > --mirror=/opt/foo > [root at cobbler-server noarch]# ll /opt/foo/*rpm | wc -l > 19 > [root at cobbler-server noarch]# > > something is not right there - just fails silently ? > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools What did you think failed? No copy occurs until you run "cobbler reposync" From tom at ng23.net Wed Apr 2 22:14:28 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 02 Apr 2008 23:14:28 +0100 Subject: [et-mgmt-tools] cobbler 0.8.x - cobbler repo update In-Reply-To: <47F400C1.7050004@redhat.com> References: <47F3DA54.5090007@ng23.net> <47F3DDB0.3000606@redhat.com> <47F4005D.1040700@ng23.net> <47F400C1.7050004@redhat.com> Message-ID: <47F40544.5050701@ng23.net> Michael DeHaan wrote: > Tom Brown wrote: >> >>> >>> If you want to maintain your own repo with rpms, all you have to do >>> is ... >>> >>> mkdir /opt/foo >>> cp /opt/foo >>> cobbler repo add --name=foo-name --mirror=/opt/foo >>> (this actually uses rsync, so if you have another box in your org, >>> with a directory full of RPMs, you can pass in >>> --mirror=user at server:/opt/foo) >>> >>> And it will take care of calling createrepo and making sure the repo >>> config files are all created correctly. >>> >>> I'd recommend doing that rather than trying to add an RPM to an >>> existing mirrored repo, as that will make it clearer what comes from >>> where and you can enable/disable individual repos as needed. >>> >> >> [root at cobbler-server noarch]# mkdir /opt/foo >> [root at cobbler-server noarch]# cp *rpm /opt/foo/ >> [root at cobbler-server noarch]# cobbler repo add --name=testing-extras >> --mirror=/opt/foo >> [root at cobbler-server noarch]# ll /opt/foo/*rpm | wc -l >> 19 >> [root at cobbler-server noarch]# >> >> something is not right there - just fails silently ? >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > What did you think failed? > > No copy occurs until you run "cobbler reposync" > ah ok my mistake From crobinso at redhat.com Thu Apr 3 16:23:43 2008 From: crobinso at redhat.com (Cole Robinson) Date: Thu, 03 Apr 2008 12:23:43 -0400 Subject: [et-mgmt-tools] [PATCH] remove showing incorrect partition size on guest OS installation In-Reply-To: <47F1D5AE.8030008@aa.jp.fujitsu.com> References: <47F1D5AE.8030008@aa.jp.fujitsu.com> Message-ID: <47F5048F.1010303@redhat.com> Hiroyuki Kaguchi wrote: > When we install guest OS to a partition by virt-manager, > the "Ready to begin installation" window shows > the size of "Simple File", NOT the size of the partition. > > I make a patch that it displays "-" as the size of the storage-partition > for this partition case. > > Signed-off-by: Hiroyuki Kaguchi > Thanks, I've applied this: http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=c12adf726fd1 - Cole From mdehaan at redhat.com Thu Apr 3 20:24:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 03 Apr 2008 16:24:52 -0400 Subject: [et-mgmt-tools] Cobbler and the ownership module, question about policies? In-Reply-To: <47F15937.90906@redhat.com> References: <47F15937.90906@redhat.com> Message-ID: <47F53D14.60901@redhat.com> Michael DeHaan wrote: > So, > > Warning -- technical email :) > > I have a pretty good ownership module going for Cobbler now > (https://fedorahosted.org/cobbler/wiki/CustomizableAuthorization), > that allows you to say that objects are owned by certain users and/or > groups, and prevents users not in those groups (except for an admin > group) to be able to edit those objects. This is designed for very > large organizations that may want lab admins to control certain > profiles, but not all of them (for instance, a build lab versus a test > lab versus a production datacenter, etc). > In this implementation, users in the admin group have access to all > objects always, and by default all objects are created with no editing > restrictions unless the creator decides to lock them down. [snip] So I have what we have currently implemented written up here: https://fedorahosted.org/cobbler/wiki/AuthorizationWithOwnership Comments/reviewers welcome. If you would like to test out this code, or the LDAP code, see the "devel" branch in git. If you're not familiar with git, there are some relevant commands at the top of this page: https://fedorahosted.org/cobbler/wiki/PatchProcess This policy seems fairly reasonable to me and should allow Cobbler server admins to offload a fair amount of work to people who own certain labs/machines/profiles, without also making the UI terribly hard to use. And, as mentioned before, the old "if you can log in, you're in" policy is still the default... you do have to turn the ownership system on. This is still in line for the 1.0 release, as are most likely improvements to Kerb eros support and the rest of the items here: https://fedorahosted.org/cobbler/wiki/TheRoadmap Thanks! --Michael From terry.mcintyre at gmail.com Thu Apr 3 22:42:31 2008 From: terry.mcintyre at gmail.com (Terry McIntyre) Date: Thu, 3 Apr 2008 15:42:31 -0700 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? Message-ID: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> I've been trying to get a kickstart working with cobbler for a while, and it just isn't working. I am totally missing something, but what? The target system: IBM x3850 M/T 8864 Trying to install RHEL 4.4 I added -vvvv flags to /etc/xinet.d/tftp to follow the progress of tftp Apr 3 22:17:57 admin in.tftpd[3261]: RRQ from 192.168.62.172 filename /pxelinux.0 Apr 3 22:17:57 admin in.tftpd[3261]: tftp: client does not accept options Apr 3 22:17:57 admin in.tftpd[3262]: RRQ from 192.168.62.172 filename /pxelinux.0 Apr 3 22:17:59 admin in.tftpd[3263]: RRQ from 192.168.62.172 filename /pxelinux.cfg/01-00-14-5e-bc-69-e2 Apr 3 22:17:59 admin in.tftpd[3264]: RRQ from 192.168.62.172 filename //images/rhel4.4/vmlinuz Apr 3 22:17:59 admin in.tftpd[3265]: RRQ from 192.168.62.172 filename //images/rhel4.4/initrd.img -- which looks reasonable. All files listed above exist, and are world-readable. Contents of /pxelinux.cfg/01-00-14-5e-bc-69-e2 default linux prompt 0 timeout 1 label linux kernel /images/rhel4.4/vmlinuz append ksdevice=eth0 lang=en_US text syslog=192.168.63.57:25150 initrd=/images/rhel4.4/initrd.img ks=http://192.168.63.57/cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg Now, when I put the http://192.168.63.57/cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg url in my browser, it works. I also see a log entry at /etc/http/logs/access_log when I request the page: 192.168.63.245 - - [03/Apr/2008:14:59:03 -0700] "GET /cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg HTTP/1.1" 200 1730 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080325 Ubuntu/7.10 (gutsy) Firefox/2.0.0.13" When I boot the server from the network, I do not see a log entry for the kickstart file, and it requests a dynamic IP address in spite of the kickstart file specifying a static IP address. #System language lang en_US #Language modules to install langsupport en_US #System keyboard keyboard us #System mouse mouse #Sytem timezone timezone --utc America/Los_Angeles #Root password rootpw changeme #Reboot after installation reboot #Use text mode install text #Install OS instead of upgrade install #Use Web installation url --url http://192.168.63.57/4.4/OneCd/ #System bootloader configuration bootloader --location=mbr #Clear the Master Boot Record zerombr yes #Partition clearing information clearpart --all --initlabel #Disk partitioning information part / --fstype ext3 --size 5000 part /boot --fstype ext3 --size 300 part swap --size 10240 part /var --fstype ext3 --size 5120 part /home --fstype ext3 --size 3036 part /opt --fstype ext3 --size 3036 part /usr --fstype ext3 --size 1 --grow #System authorization infomation auth --useshadow --enablemd5 network --bootproto=static --ip=192.168.62.172 --netmask=255.255.254.0 --gateway=192.168.62.40 --nameserver=192.168.67.154 --device=eth0 --hostname=rac12.crm.bizsys.tmcs --onboot=on #Firewall configuration firewall --disabled selinux --disabled # disable the firstboot config firstboot --disable #Do not configure XWindows skipx #Package install information %packages --resolvedeps @ development-tools @ admin-tools @ system-tools @ server-cfg kernel-smp grub e2fsprogs perl lynx postfix sysstat %post hostname rac12.crm.bizsys.tmcs rpm -e sendmail kudzu redhat-config-mouse kernel-pcmcia-cs ppp rp-pppoe \ wvdial redhat-config-network-tui redhat-lsb chkconfig keytable off chkconfig rhnsd off chkconfig iptables off chkconfig xfs off chkconfig gpm off chkconfig --level 345 ntpd on chkconfig --level 345 snmpd on chkconfig --level 2345 postfix on Thanks in advance for any assistance! -- Terry McIntyre UNIX for hire Software Development, Systems Administration, Security terry.mcintyre at gmail.com From berrange at redhat.com Fri Apr 4 14:15:58 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 4 Apr 2008 15:15:58 +0100 Subject: [et-mgmt-tools] FYI: Reporting 'upstream' bugs for libvirt & virt tools Message-ID: <20080404141558.GA24886@redhat.com> This is a quick mail to let people know of a new bug reporting policy for virtualization related tools. 1. Only, if you are using binary RPMs from official Fedora repositories, bugs should be reported under the 'Fedora' product, with the component matching the RPM you're reporting against: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora 2. For all other cases. ie If you are using self-built binaries, or checkouts from the source repos, or forwarding bugs from a non-Fedora distribution, then use the generic 'Virtualization Tools' product: https://bugzilla.redhat.com/enter_bug.cgi?product=Virtualization%20Tools This is our master 'upstream' bug tracking product now. This is important because Fedora recently instituted a number of bug house keeping policies against things under 'Fedora', which may result in your bugs being incorrectly closed. Using 'Virtualization Tools' product in bugzilla ensures we can distinguish upstream bugs from Fedora bugs. This applies to the following applications: libvirt virt-df virt-manager virt-p2v virt-top virt-viewer virtinst Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Fri Apr 4 14:41:47 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 04 Apr 2008 10:41:47 -0400 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> Message-ID: <47F63E2B.6020409@redhat.com> Terry McIntyre wrote: > I've been trying to get a kickstart working with cobbler for a while, > and it just isn't working. I am totally missing something, but what? > Ok, so you're PXE'ing the system.... I don't have all the information I need to go on, so I'll start you off with some info and if you still have problems we can take it from there. In order for PXE to work, several conditions must be satisifed. "Cobbler check" looks after most of these and will let you know about most of the common setup problems. If you have not run "cobbler check", do so now and fix any errors it reports. The most common problem is if your DHCP server does not set a "next-server" line, which is especially likely if DHCP is run from another box and is not under your control. If this happens, your server will be requesting PXE files from /another/ box or possibly none at all. The next-server in your DHCP config must point at your cobbler server. If using cobbler to manage a dhcp configuration, most of this is provided for you, and that information is included on the main cobbler page and on the Wiki... most likely you already have working DHCP so you just need to talk with your DHCP admin. First check to see that while your computer is booting, that it is contacting a server over TFTP and that this is your cobbler server. As for your server requesting a dynamic IP when booting, this is normal, and is required in order to actually use PXE. The system will DHCP for the first time and then configure the system for a static IP on subsequent restarts. If you do not see your computer requesting a TFTP file while it is booting -- that's a DHCP problem. If it successfully requests the kernel/initrd, goes into Anaconda, and then just doesn't request the kickstart file, that's more of an indication that the web server is not reachable from the install location -- which is a network problem. If that is the case, use a machine on the network to verify the kickstart file can be retrieved with wget/curl or a browser. I also saw from IRC last night you're using a pretty old version of Cobbler -- PXE has worked fine in all versions, though you should upgrade to 0.8.2. It will make debugging easier and eliminate some potential communication errors when talking about things. The latest version of Cobbler is available in EPEL for both EL4 and 5 according to the instructions on the Cobbler download page. Hopefully that helps, if not, let me know more info and we'll see if we can't fix you... --Michael > The target system: IBM x3850 M/T 8864 > Trying to install RHEL 4.4 > > I added -vvvv flags to /etc/xinet.d/tftp to follow the progress of tftp > > Apr 3 22:17:57 admin in.tftpd[3261]: RRQ from 192.168.62.172 filename > /pxelinux.0 > Apr 3 22:17:57 admin in.tftpd[3261]: tftp: client does not accept options > Apr 3 22:17:57 admin in.tftpd[3262]: RRQ from 192.168.62.172 filename > /pxelinux.0 > Apr 3 22:17:59 admin in.tftpd[3263]: RRQ from 192.168.62.172 filename > /pxelinux.cfg/01-00-14-5e-bc-69-e2 > Apr 3 22:17:59 admin in.tftpd[3264]: RRQ from 192.168.62.172 filename > //images/rhel4.4/vmlinuz > Apr 3 22:17:59 admin in.tftpd[3265]: RRQ from 192.168.62.172 filename > //images/rhel4.4/initrd.img > > -- which looks reasonable. All files listed above exist, and are > world-readable. > > Contents of /pxelinux.cfg/01-00-14-5e-bc-69-e2 > > default linux > prompt 0 > timeout 1 > label linux > kernel /images/rhel4.4/vmlinuz > append ksdevice=eth0 lang=en_US text > syslog=192.168.63.57:25150 initrd=/images/rhel4.4/initrd.img > ks=http://192.168.63.57/cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg > > Now, when I put the > http://192.168.63.57/cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg url > in my browser, it works. I also see a log entry at > /etc/http/logs/access_log when I request the page: > > 192.168.63.245 - - [03/Apr/2008:14:59:03 -0700] "GET > /cblr/kickstarts_sys/00:14:5e:bc:69:e2/ks.cfg HTTP/1.1" 200 1730 "-" > "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080325 > Ubuntu/7.10 (gutsy) Firefox/2.0.0.13" > > When I boot the server from the network, I do not see a log entry for > the kickstart file, and it requests a dynamic IP address in spite of > the kickstart file specifying a static IP address. > > #System language > lang en_US > #Language modules to install > langsupport en_US > #System keyboard > keyboard us > #System mouse > mouse > #Sytem timezone > timezone --utc America/Los_Angeles > #Root password > rootpw changeme > #Reboot after installation > reboot > #Use text mode install > text > #Install OS instead of upgrade > install > #Use Web installation > url --url http://192.168.63.57/4.4/OneCd/ > #System bootloader configuration > bootloader --location=mbr > #Clear the Master Boot Record > zerombr yes > #Partition clearing information > clearpart --all --initlabel > #Disk partitioning information > part / --fstype ext3 --size 5000 > part /boot --fstype ext3 --size 300 > part swap --size 10240 > part /var --fstype ext3 --size 5120 > part /home --fstype ext3 --size 3036 > part /opt --fstype ext3 --size 3036 > part /usr --fstype ext3 --size 1 --grow > #System authorization infomation > auth --useshadow --enablemd5 > network --bootproto=static --ip=192.168.62.172 --netmask=255.255.254.0 > --gateway=192.168.62.40 --nameserver=192.168.67.154 --device=eth0 > --hostname=rac12.crm.bizsys.tmcs --onboot=on > #Firewall configuration > firewall --disabled > selinux --disabled > # disable the firstboot config > firstboot --disable > #Do not configure XWindows > skipx > #Package install information > %packages --resolvedeps > @ development-tools > @ admin-tools > @ system-tools > @ server-cfg > kernel-smp > grub > e2fsprogs > perl > lynx > postfix > sysstat > %post > > hostname rac12.crm.bizsys.tmcs > > rpm -e sendmail kudzu redhat-config-mouse kernel-pcmcia-cs ppp rp-pppoe \ > wvdial redhat-config-network-tui redhat-lsb > > chkconfig keytable off > chkconfig rhnsd off > chkconfig iptables off > chkconfig xfs off > chkconfig gpm off > chkconfig --level 345 ntpd on > chkconfig --level 345 snmpd on > chkconfig --level 2345 postfix on > > > Thanks in advance for any assistance! > > > > > From chekh at pcbi.upenn.edu Fri Apr 4 14:43:55 2008 From: chekh at pcbi.upenn.edu (Alex Chekholko) Date: Fri, 4 Apr 2008 10:43:55 -0400 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> Message-ID: <20080404104355.96164dfa.chekh@pcbi.upenn.edu> On Thu, 3 Apr 2008 15:42:31 -0700 "Terry McIntyre" wrote: > I've been trying to get a kickstart working with cobbler for a while, > and it just isn't working. I am totally missing something, but what? > > The target system: IBM x3850 M/T 8864 > Trying to install RHEL 4.4 > Does this machine have multiple NICs? What happens if you disable all but one? I had a similar problem, and that was my solution, documented here: http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/258002348831 HTH, -- Alex Chekholko From mdehaan at redhat.com Fri Apr 4 15:49:03 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 04 Apr 2008 11:49:03 -0400 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <20080404104355.96164dfa.chekh@pcbi.upenn.edu> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> <20080404104355.96164dfa.chekh@pcbi.upenn.edu> Message-ID: <47F64DEF.80802@redhat.com> Alex Chekholko wrote: > On Thu, 3 Apr 2008 15:42:31 -0700 > "Terry McIntyre" wrote: > > >> I've been trying to get a kickstart working with cobbler for a while, >> and it just isn't working. I am totally missing something, but what? >> >> The target system: IBM x3850 M/T 8864 >> Trying to install RHEL 4.4 >> >> > > Does this machine have multiple NICs? What happens if you disable all > but one? > > I had a similar problem, and that was my solution, documented here: > http://episteme.arstechnica.com/eve/forums/a/tpc/f/96509133/m/258002348831 > > HTH, > Cobbler makes this pretty easy now -- so you can set it up to PXE off either interface. You can add multiple NICs to your system records. I originally added this for creating dual-homed virtual machines, but it works just as well to help PXE physical boxes. cobbler system add --name=demobox --mac=AA:BB:CC:DD:EE:EE --profile=demoprofile cobbler system edit --name=demobox --interface=1 --mac=AA:BB:CC:DD:EE:FF The first edit applies to interface 0 (the default), and in the second invocation, we are editing interface 1. There is no actual correlation between the numbers and the "eth0/eth1" numbers you'll get later ... it's the MAC that matters. The only catch here is that if you need to edit them one at a time (this was done to keep the command line parser simple) and if you add one too many, you can only delete them through the web interface. Using multiple interfaces is actually a a lot easier to visualize when using the WebUI, so I recommend taking a look at that. --Michael From terry.mcintyre at gmail.com Fri Apr 4 15:58:41 2008 From: terry.mcintyre at gmail.com (Terry McIntyre) Date: Fri, 4 Apr 2008 08:58:41 -0700 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <47F63E2B.6020409@redhat.com> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> <47F63E2B.6020409@redhat.com> Message-ID: <67f096ea0804040858nc9d1f18u52f4b8f65f35617b@mail.gmail.com> Thanks for the tips. I am using cobbler to manage the dhcp, it does have the next-server lines, the dhcp and tftp logs ( using -vvvv ) switch show everything working up to the point of requesting the htttp: kickstart file. I did pull that file from another machine ( my laptop, using http ) on the same network. Used the exact same URL cut-n-pasted from the cobbler file. Therefore, the www server seems to be working fine, as is the network. Only one interface is connected to the network; there are four interfaces. I do not set up the other three in the kickstart file, but that probably does not matter, since the kickstart file is not being used. Am upgrading cobbler -- will try again shortly. Thanks again! From rigg0022 at umn.edu Fri Apr 4 17:22:35 2008 From: rigg0022 at umn.edu (Ben Riggs) Date: Fri, 04 Apr 2008 12:22:35 -0500 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <67f096ea0804040858nc9d1f18u52f4b8f65f35617b@mail.gmail.com> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> <47F63E2B.6020409@redhat.com> <67f096ea0804040858nc9d1f18u52f4b8f65f35617b@mail.gmail.com> Message-ID: <47F663DB.5040503@umn.edu> To be sure that anaconda is using the card you want it to (I've noticed inconsistencies between the eth#s in bios, anaconda & 'normal' kernels), add --kopts="device=$nic_mac_address" Terry McIntyre wrote: > Thanks for the tips. I am using cobbler to manage the dhcp, it does > have the next-server lines, the dhcp and tftp logs ( using -vvvv ) > switch show everything working up to the point of requesting the > htttp: kickstart file. > > I did pull that file from another machine ( my laptop, using http ) on > the same network. Used the exact same URL cut-n-pasted from the > cobbler file. Therefore, the www server seems to be working fine, as > is the network. > > Only one interface is connected to the network; there are four > interfaces. I do not set up the other three in the kickstart file, but > that probably does not matter, since the kickstart file is not being > used. > > Am upgrading cobbler -- will try again shortly. > > Thanks again! > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From terry.mcintyre at gmail.com Fri Apr 4 22:59:46 2008 From: terry.mcintyre at gmail.com (Terry McIntyre) Date: Fri, 4 Apr 2008 15:59:46 -0700 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <47F663DB.5040503@umn.edu> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> <47F63E2B.6020409@redhat.com> <67f096ea0804040858nc9d1f18u52f4b8f65f35617b@mail.gmail.com> <47F663DB.5040503@umn.edu> Message-ID: <67f096ea0804041559q17200080r3cc2698bf7237dae@mail.gmail.com> On Fri, Apr 4, 2008 at 10:22 AM, Ben Riggs wrote: > To be sure that anaconda is using the card you want it to (I've noticed > inconsistencies between the eth#s in bios, anaconda & 'normal' kernels), add > --kopts="device=$nic_mac_address" Ok, I used --kopts="device=", and it is reflected in the /var/lib/cobbler/systems file: depth: 2 interfaces: intf0: dhcp_tag: '' gateway: '192.168.62.40' hostname: rac12 ip_address: '192.168.62.172' mac_address: '00:15:17:3a:c2:78' subnet: '' virt_bridge: '' intf1: dhcp_tag: '' gateway: '' hostname: '' ip_address: '192.168.62.173' mac_address: '00:14:5e:bc:69:e2' subnet: '' virt_bridge: '' kernel_options: device: '00:15:17:3a:c2:78' kickstart: <> ks_meta: hostname: rac12.crm.bizsys.tmcs ip: '192.168.62.172' name: '00:15:17:3a:c2:78' netboot_enabled: True Here's tail -f /var/log/messages: Apr 4 15:39:22 admin dhcpd: dhcpd startup succeeded Apr 4 15:39:22 admin dhcpd: dhcpd startup succeeded Apr 4 15:42:52 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:42:52 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 15:42:54 admin dhcpd: DHCPREQUEST for 192.168.62.172 (192.168.63.57) from 00:15:17:3a:c2:78 via eth0 Apr 4 15:42:54 admin dhcpd: DHCPACK on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 22:42:54 admin in.tftpd[19942]: RRQ from 192.168.62.172 filename /pxelinux.0 Apr 4 22:42:54 admin in.tftpd[19942]: tftp: client does not accept options Apr 4 22:42:54 admin in.tftpd[19943]: RRQ from 192.168.62.172 filename /pxelinux.0 Apr 4 22:42:56 admin in.tftpd[19944]: RRQ from 192.168.62.172 filename /pxelinux.cfg/01-00-15-17-3a-c2-78 Apr 4 22:42:56 admin in.tftpd[19945]: RRQ from 192.168.62.172 filename //images/rhel4.4/vmlinuz Apr 4 22:42:57 admin in.tftpd[19946]: RRQ from 192.168.62.172 filename //images/rhel4.4/initrd.img At this point it is booting, I see an anaconda version, and /sbin/loader next thing is a screen requesting IP address via dhcp. Apr 4 15:43:23 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:23 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:29 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:29 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:40 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:40 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:50 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:50 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:50 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 Apr 4 15:43:50 admin dhcpd: DHCPOFFER on 192.168.62.172 to 00:15:17:3a:c2:78 via eth0 Why is it looping? After this loop, Anaconda then shows the "Use dynamic IP configuration" screen. The kickstart file ( referenced here ) is not being requested, so far as I can tell: [root at admin pxelinux.cfg]# cat /tftpboot/pxelinux.cfg/01-00-15-17-3a-c2-78 default linux prompt 0 timeout 1 label linux kernel /images/rhel4.4/vmlinuz append ksdevice=eth0 lang=en_US text syslog=192.168.63.57:25150 device=00:15:17:3a:c2:78 kssendmac initrd=/images/rhel4.4/initrd.img ks=http://192.168.63.57/cblr/kickstarts_sys/00:15:17:3a:c2:78/ks.cfg Oddly, there is no newline on the last line of this file. I cut-n-pasted this url http://192.168.63.57/cblr/kickstarts_sys/00:15:17:3a:c2:78/ks.cfg into a browser on my laptop on the same network, and it worked properly. /etc/httpd/logs/access_log shows my request ( by hand ); it shows no previous request from anaconda. I added a linefeed to the end of the pxelinux.cfg file and tried again. No change in behavior. From mdehaan at redhat.com Sat Apr 5 00:28:10 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 04 Apr 2008 20:28:10 -0400 Subject: [et-mgmt-tools] cobbler kickstart does not pull in the http: ks file? In-Reply-To: <67f096ea0804041559q17200080r3cc2698bf7237dae@mail.gmail.com> References: <67f096ea0804031542m16f10405sf41ab88b9faa2ffc@mail.gmail.com> <47F63E2B.6020409@redhat.com> <67f096ea0804040858nc9d1f18u52f4b8f65f35617b@mail.gmail.com> <47F663DB.5040503@umn.edu> <67f096ea0804041559q17200080r3cc2698bf7237dae@mail.gmail.com> Message-ID: <47F6C79A.7080907@redhat.com> > Apr 4 15:43:23 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:23 admin dhcpd: DHCPOFFER on 192.168.62.172 to > 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:29 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:29 admin dhcpd: DHCPOFFER on 192.168.62.172 to > 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:40 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:40 admin dhcpd: DHCPOFFER on 192.168.62.172 to > 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:50 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:50 admin dhcpd: DHCPOFFER on 192.168.62.172 to > 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:50 admin dhcpd: DHCPDISCOVER from 00:15:17:3a:c2:78 via eth0 > Apr 4 15:43:50 admin dhcpd: DHCPOFFER on 192.168.62.172 to > 00:15:17:3a:c2:78 via eth0 > > Why is it looping? > Ah, the dreaded installer DHCP problem. This seems to indicate that your system failed to DHCP in time. There are known timing issues with Anaconda at that stage, after it resets the network card, where pump doesn't have a sufficiently long timeout. Here's a custom search engine for kickstart-list at redhat.com: http://www.google.com/coop/cse?cx=016811804524159694721%3A1h7btspnxtu It probably is a network configuration issue -- most likely this one: http://www.redhat.com/archives/kickstart-list/2002-August/msg00041.html There's also a writeup here: http://fedoraproject.org/wiki/Anaconda/NetworkIssues Hopefully that gets you further along. If Anaconda can't get network info, it will prompt for it -- it never had a chance to request the kickstart in your case because it didn't have an IP at that stage. --Michael From lhaig at haigmail.com Sun Apr 6 12:16:13 2008 From: lhaig at haigmail.com (Lance Haig) Date: Sun, 06 Apr 2008 13:16:13 +0100 Subject: [et-mgmt-tools] Packaging virt-manager for forsightlinux Message-ID: <47F8BF0D.50500@haigmail.com> Hi, I am trying to package virt-manager, virtinst and virt-viewer for foresight linux. I have been able to package virt-manager and virtinst. When I run virt-manager and try to connect to the local machine with kvm/qemu installed it gives me a traceback about libvirtd not running. I have libvirt installed as I can run kvm/qemu machines without much fuss. Have I missed something? Regards Lance From lippold at gmail.com Sun Apr 6 18:35:49 2008 From: lippold at gmail.com (Aaron Lippold) Date: Sun, 6 Apr 2008 14:35:49 -0400 Subject: [et-mgmt-tools] "Snippet Groups" Message-ID: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> Hi All, I did some chatting on the irc on this but wanted to post it to the list to get some feedback. I have some KS files already which setup and secure my systems to my organizations standards. I'd like to break up and generlize my processes and "scripts" - mainly in the post section - into smaller chunks to make it more flexible and manageable. I know I can do includes, snippets and triggers. The idea would be that I could have a "Core Set" of items that I could include into my ks template - OS::Lockdown - which would include / call a known set of actions. I could then develop other "sets" - MySQL, Apache, Oracle, etc. I am hoping that I could also then use those separable pieces after updates and patches to "reverify" the systems - assume I already have a set of scripts that I can run that will give me a list ( Item1, Item2, Item3) which require an action. With a little scripting and a "map" - flat txt with "Item1:OS::Boot::Action: - I could run each item that needs to be fixed again. I think this would be valueable because it would give the end user the ablity to divorce "interface from implamentation" as it were. It would allow you to use cobbler to also assist with maintaining the baseline etc. The question is which path to take. Thoughts, suggestions, "idiot, you can do that like this" would be appriciated :). Thanks, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssklar at stanford.edu Sun Apr 6 18:57:49 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Sun, 6 Apr 2008 11:57:49 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" Message-ID: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> I'd like to use snippets in my kickstart file for selecting things like partitioning, packages, and post portions based on either user- provided ksmeta variables or the Cobbler-provided variables. Unfortunately, I know very little Python, and my googling around for Cheetah examples of what I'd like to do has been less then fruitful. Example: In my /etc/cobbler/rhel5xen.ks kickstart template, I've got ... %packages SNIPPET::packages_select What I'd like that file /usr/lib/cobbler/snippets/packages_select is to do something like (in psuedo-code here; if I could write the "real" code, I wouldn't be asking. :-) ==================================== $package_snip_dir = /var/lib/cobbler/snippets/packages.d If if the ksmeta var "$packages" has a value AND if $package_snip_dir/ $packages exists , use it ... ... else if $package_snip_dir/$name exists, use it ... ... else if $package_snip_dir/$profile exists, use it ... ... else, use $package_snip_dir/default. =================================== I've tried making this work, with "#try ... #except ... #finally" blocks, "#if ... #elif ... #then" blocks, "os.path.isfile", and so on. All of my attempts have ended in various syntax errors or failures that I'm at a loss to resolve. I expect that the solution to this is simple, and I'm going to feel really stupid when someone points that solution out to me, but I can live with that. :-) Below is my last, best attempt, along with the error that gets generated. [root ~]# cat /var/lib/cobbler/snippets/packages_select #try #include raw source='/var/lib/cobbler/snippets/packages.d/' + $packages #except #try #include raw source='/var/lib/cobbler/snippets/packages.d/' + $name #except #try #include raw source='/var/lib/cobbler/snippets/packages.d/' + $profile #except #try #include raw "/var/lib/cobbler/snippets/packages.d/DEFAULT" #end try #end try #end try #end try [root ~]# cobbler sync sync distro: rhel4AS-x86_64 sync distro: rhel4AS-xen-x86_64 sync distro: rhel5Server-x86_64 sync distro: rhel5Server-xen-x86_64 sync profile: xen-big Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 373, in validate_kickstart_for_specific_profile self.apply_template(kfile, meta, dest) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 627, in apply_template t = Template(source=data, searchList=[metadata]) File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line 1204, in __init__ self._compile(source, file, compilerSettings=compilerSettings) File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line 1492, in _compile keepRefToGeneratedCode=True) File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line 791, in compile raise parseError ParseError: Error in the Python code which Cheetah generated for this template: = = = = = = = = ======================================================================== invalid syntax (cheetah_DynamicallyCompiledCheetahTemplate_1207508119_67_52126.py, line 210) Line|Python Code ----|------------------------------------------------------------- 208 | try: # generated from line 51, col 4 209 | self._handleCheetahInclude("/var/lib/ cobbler/snippets/packages.d/DEFAULT", trans=trans, includeFrom="file", raw=True) 210 | write(''' ^ 211 |%post 212 | 213 |''') = = = = = = = = ======================================================================== Here is the corresponding Cheetah code. ** I had to guess the line & column numbers, so they are probably incorrect: Line 61, column 1 Line|Cheetah Code ----|------------------------------------------------------------- 58 | 59 |%post 60 | 61 |$yum_config_stanza ^ 62 | 63 |## post_select 64 |## Error while rendering kickstart file /etc/cobbler/rhel5xen.ks to /var/ www/cobbler/kickstarts/xen-big/ks.cfg From mdehaan at redhat.com Mon Apr 7 15:08:43 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 Apr 2008 11:08:43 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> Message-ID: <47FA38FB.7060907@redhat.com> Aaron Lippold wrote: > Hi All, > > I did some chatting on the irc on this but wanted to post it to the > list to get some feedback. > > I have some KS files already which setup and secure my systems to my > organizations standards. I'd like to break up and generlize my > processes and "scripts" - mainly in the post section - into smaller > chunks to make it more flexible and manageable. I know I can do > includes, snippets and triggers. The idea would be that I could have a > "Core Set" of items that I could include into my ks template - > OS::Lockdown - which would include / call a known set of actions. I > could then develop other "sets" - MySQL, Apache, Oracle, etc. I am > hoping that I could also then use those separable pieces after updates > and patches to "reverify" the systems - assume I already have a set of > scripts that I can run that will give me a list ( Item1, Item2, Item3) > which require an action. With a little scripting and a "map" - flat > txt with "Item1:OS::Boot::Action: - I could run each item that needs > to be fixed again. > > I think this would be valueable because it would give the end user the > ablity to divorce "interface from implamentation" as it were. It would > allow you to use cobbler to also assist with maintaining the baseline etc. > > The question is which path to take. Thoughts, suggestions, "idiot, > you can do that like this" would be appriciated :). > > Thanks, > > Aaron I'm not sure I understand what this would look like. Could you possibly throw out some syntax of what that might look like in the template file and how the files might be layed out behind the scenes? Right now snippets work as includes ... in fact, it's conceptually "just" a Cheetah (Cobbler's templating language) include at this point. SNIPPET::foo just includes "/var/lib/cobbler/snippets/foo any time it is present in the file. Can you explain further? --Michael From mdehaan at redhat.com Mon Apr 7 15:42:22 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 Apr 2008 11:42:22 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> Message-ID: <47FA40DE.2080504@redhat.com> Sandor W. Sklar wrote: > I would probably solve the problem of sourcing the packages list from an external file in a different way... For starters, assume you have your packages list arranged as follows: /var/www/html/packages_list/systems/* (file named after systems go heere) /var/www/html/packages_list/profiles/* (file named after profiles go here) /var/www/html/packages_list/default (default files go here) What follows is a bash script for the kickstart .. the format is slightly different as we have to escape the bash for Cheetah -- and we also need to do a quick trick to pass Cheetah variables into the bash section as bash variables... So that's what the first four lines up to "#raw" do. you can validate that this works for you by running "cobbler sync" and then looking at http://server/cobbler/kickstart_sys/name/ks.cfg to make sure it's templated out with URLs/values that look good to you, though this should be pretty close. Basically it makes three seperate wget requests and stops when it gets a file that is not zero length. Once it has the file saved to /tmp/packages we later include (using kickstart) the file /tmp/packages into the middle of the package list at runtime. This also allows the package list to be modified without having to run "cobbler sync" to apply changes to it. %pre profile = $profile name = $name server = $server #raw wget http://$server/packages_list/systems/$name -O /tmp/packages if [ ! -s /tmp/packages ] then wget http://$server/packages_list/profiles/$profile -O /tmp/packages if [ ! -s /tmp/packages ] then wget http://$server/packages_list/default -O /tmp/packages fi fi #endraw In your %packages section: %include /tmp/packages Will that work? That's a pretty good idea for a way to source a packages list, so I may include that snippet in a future release of Cobbler if it meets requirements. We could carve out space in /var/www/cobbler to store the packages lists and include info on the Wiki about how to use it. (Note that right now, that's not advisable, as cobbler cleans out content in /var/www/cobbler each time it runs). --Michael From ssklar at stanford.edu Mon Apr 7 16:01:49 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Mon, 7 Apr 2008 09:01:49 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <47FA40DE.2080504@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> Message-ID: On Apr 7, 2008, at 8:42 AM, Michael DeHaan wrote: > Sandor W. Sklar wrote: >> > > I would probably solve the problem of sourcing the packages list > from an external file in a different way... Hi, Michael, Thanks; I hadn't thought of doing it that way. I'd prefer that the cobbler-rendered kickstarts were "complete", but it seems that this is a good workaround that accomplishes what I'm trying to do. Knowing very little of python (guess I'm going to have to crack a book some day), can I assume that doing what I originally hoped for would be too awkward? ( I use that word instead of "not possible", because the Perl that I know has let me to understand that nothing is impossible! :-) Thanks, -s- From mdehaan at redhat.com Mon Apr 7 16:13:46 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 Apr 2008 12:13:46 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> Message-ID: <47FA483A.2040401@redhat.com> Sandor W. Sklar wrote: > > On Apr 7, 2008, at 8:42 AM, Michael DeHaan wrote: >> Sandor W. Sklar wrote: >>> >> >> I would probably solve the problem of sourcing the packages list from >> an external file in a different way... > > Hi, Michael, > > Thanks; I hadn't thought of doing it that way. I'd prefer that the > cobbler-rendered kickstarts were "complete", but it seems that this is > a good workaround that accomplishes what I'm trying to do. I'll file an RFE on exploring it this way. > > Knowing very little of python (guess I'm going to have to crack a book > some day), can I assume that doing what I originally hoped for would > be too awkward? ( I use that word instead of "not possible", because > the Perl that I know has let me to understand that nothing is > impossible! :-) Kinda, in general a template that tries to test for existance of a file on the filesystem starts being more "code" than template. That can get scary, as you've seen. Cheetah does allow blurring that line, but I like keeping the template files as "data" for basic string substitution and not pushing it that far. This isn't to say we can't achieve a similar solution in Cobbler itself, that may be more elegant than either option. I'll open up a RFE on this to see what the options are -- things that allow someone to edit kickstarts /less/ would be good, and I can see something like this even being presented in the UI. We could have cobbler automatically include content from /var/lib/cobbler/packages_list/profiles/$name and /var/lib/cobbler/packages_list/systems/$name every time we sync if we wanted to. We do have the question then of what gets appended to a list or what gets used /instead/, and which use case is more important. I can kind of see cases for both. Ideally one wouldn't be assigning specific packages to specific systems, as the point of a profile is to make a configuration available to all things that look "like" something. Can you explain your use case for assigning specific packages to specific systems? Thoughts on how that should work? I do like this idea a lot... --Michael From ssklar at stanford.edu Mon Apr 7 17:56:43 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Mon, 7 Apr 2008 10:56:43 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <47FA483A.2040401@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> Message-ID: <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> On Apr 7, 2008, at 9:13 AM, Michael DeHaan wrote: > > We could have cobbler automatically include content from /var/lib/ > cobbler/packages_list/profiles/$name and /var/lib/cobbler/ > packages_list/systems/$name every time we sync if we wanted to. We > do have the question then of what gets appended to a list or what > gets used /instead/, and which use case is more important. I can > kind of see cases for both. Agreed. Also keep in mind that I used "packages" as an example; I'm hoping to use the same method with the disk partitioning section of the ks, as well as the post section (and, I guess, for the pre section as well; always forget about that one. :-) > > > Ideally one wouldn't be assigning specific packages to specific > systems, as the point of a profile is to make a configuration > available to all things that look "like" something. Can you explain > your use case for assigning specific packages to specific systems? Good question. I agree that it would be rare to have something assigned on a "system" basis, as opposed to a profile. That said, I've taken responsibility for setting up the Cobbler environment for my team of sysadmins, and I guess I'm just anticipating the probability that one of them would say, "what if I want X, Y, and Z only for one system, and I don't want to make a separate profile." Fairly contrived example, I think, but I won't be surprised to have it posed to me. :-) > > Thoughts on how that should work? Well, in my "perfect" world, I kind of like the pseudo-code from my original email, but I understand the desire to keep more complex code out of what should be a template. I guess, if you start with the idea that a proper kickstart file has four "official" sections[1] (command, %packages, %pre, %post), it would make sense to maybe have each of those items defined as standard cobbler profile metadata; doing so would completely modularize kickstart generation. I'm sure there are holes in that logic (one is, I actually consider the "disk partitioning" a separate section, but it "officially" is just a part of the "command" section. Doubtless there are other holes that I'm not seeing right now. > > > I do like this idea a lot... Thanks! I like cobbler a lot! -s- [1] From mdehaan at redhat.com Mon Apr 7 18:06:43 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 07 Apr 2008 14:06:43 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> Message-ID: <47FA62B3.2050309@redhat.com> Sandor W. Sklar wrote: > > On Apr 7, 2008, at 9:13 AM, Michael DeHaan wrote: >> >> We could have cobbler automatically include content from >> /var/lib/cobbler/packages_list/profiles/$name and >> /var/lib/cobbler/packages_list/systems/$name every time we sync if we >> wanted to. We do have the question then of what gets appended to a >> list or what gets used /instead/, and which use case is more >> important. I can kind of see cases for both. > > Agreed. Also keep in mind that I used "packages" as an example; I'm > hoping to use the same method with the disk partitioning section of > the ks, as well as the post section (and, I guess, for the pre section > as well; always forget about that one. :-) Yes, so really about groups of snippets then. I follow. Sounds cleaner too! This may get close to what Aaron was referring to earlier today also -- not sure. >> >> >> Ideally one wouldn't be assigning specific packages to specific >> systems, as the point of a profile is to make a configuration >> available to all things that look "like" something. Can you explain >> your use case for assigning specific packages to specific systems? > > Good question. I agree that it would be rare to have something > assigned on a "system" basis, as opposed to a profile. That said, I've > taken responsibility for setting up the Cobbler environment for my > team of sysadmins, and I guess I'm just anticipating the probability > that one of them would say, "what if I want X, Y, and Z only for one > system, and I don't want to make a separate profile." Fairly contrived > example, I think, but I won't be surprised to have it posed to me. :-) > Yes, that definitely happens... I can see that being more useful in a general context if we don't just apply it to packages. (For instance, this system has storage that is just /slightly/ off) ... at least conceptually. >> >> Thoughts on how that should work? > > Well, in my "perfect" world, I kind of like the pseudo-code from my > original email, but I understand the desire to keep more complex code > out of what should be a template. I guess, if you start with the idea > that a proper kickstart file has four "official" sections[1] (command, > %packages, %pre, %post), it would make sense to maybe have each of > those items defined as standard cobbler profile metadata; doing so > would completely modularize kickstart generation. > What if we changed the semantics of... SNIPPET::foosball which would now be smart and would pull one of the following, whichever exists first: /var/lib/cobbler/snippets/system/foosball/$system_name /var/lib/cobbler/snippets/profile/foosball/$profile_name /var/lib/cobbler/snippets/distro/foosball/$distro_name /var/lib/cobbler/snippets/foosball whichever was found first. I think this is what you're getting at and could be done fairly cleanly without being package specific. Of course the stock install would lay down none of these paths except the directories and this would largely be just documented if you decide to use it (on the Wiki). --Michael From sakaia at jp.fujitsu.com Tue Apr 8 01:36:11 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Tue, 08 Apr 2008 10:36:11 +0900 Subject: [et-mgmt-tools] [PATCH][virt-viewer][MAN] typo Message-ID: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> Hi, Dan Fix man on virt-viewer. (--help option) Thanks Atsushi SAKAI -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_virtviewer_help.patch Type: application/octet-stream Size: 301 bytes Desc: not available URL: From 1.cobbler at msquared.id.au Tue Apr 8 02:53:11 2008 From: 1.cobbler at msquared.id.au (Msquared) Date: Tue, 8 Apr 2008 10:53:11 +0800 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA483A.2040401@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> Message-ID: <20080408025310.GB16017@sliderule.msquared.net.au> On Mon, Apr 07, 2008 at 12:13:46PM -0400, Michael DeHaan wrote: > Ideally one wouldn't be assigning specific packages to specific systems, > as the point of a profile is to make a configuration available to all > things that look "like" something. Can you explain your use case for > assigning specific packages to specific systems? I can: I have two 'workstations' that run on power from a single UPS. Only one of them, however, is actually connected to the UPS' communications port - the other one talks via TCP/IP to the first to determine UPS status. All workstations have nut-client installed, but only the workstation connected to the UPS' communications port has nut installed. Granted, I could probably have a 'with-ups' profile based on the standard workstation profile, but it hardly seems worth it to me. :-) Actually, relevant question: If I have a 'workstation-with-ups' profile based on a 'workstation' profile, and add packages to the 'workstation' profile, will the packages also be automatically added to the 'workstation-with-ups' profile? (Note: I have not (yet) set up either of the aforementioned workstations with Cobbler, but they do exist and they are on a UPS via nut - it's just a valid use-case that I think bears inclusion.) On Mon, Apr 07, 2008 at 10:56:43AM -0700, Sandor W. Sklar wrote: > I'm sure there are holes in that logic (one is, I actually consider the > "disk partitioning" a separate section, but it "officially" is just a > part of the "command" section. Doubtless there are other holes that > I'm not seeing right now. The original logic seems to me that you get to choose only one snippet (system, profile, or default), but how about additive? (Perhaps a better term is inheritance...) For example, with my little workstations-on-a-UPS example, the workstation that is on the UPS will need the nut package added, but will otherwise be identical to any other workstation (I would want the UPS-connected workstation to inherit the same package list and configuration as the other workstations). Regards, Msquared... From rjones at redhat.com Tue Apr 8 10:33:53 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Apr 2008 11:33:53 +0100 Subject: [et-mgmt-tools] Packaging virt-manager for forsightlinux In-Reply-To: <47F8BF0D.50500@haigmail.com> References: <47F8BF0D.50500@haigmail.com> Message-ID: <20080408103353.GA4783@amd.home.annexia.org> On Sun, Apr 06, 2008 at 01:16:13PM +0100, Lance Haig wrote: > I am trying to package virt-manager, virtinst and virt-viewer for foresight > linux. (As background, Foresight Linux uses the Conary package manager as written by rPath: http://en.wikipedia.org/wiki/Conary_%28package_manager%29) > I have been able to package virt-manager and virtinst. When I run > virt-manager and try to connect to the local machine with kvm/qemu > installed it gives me a traceback about libvirtd not running. > > I have libvirt installed as I can run kvm/qemu machines without much fuss. Before launching into virt-manager, start with the basics. What do these commands say? virsh list virsh list --all virsh -c qemu:///system list Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Tue Apr 8 10:36:11 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 8 Apr 2008 11:36:11 +0100 Subject: [et-mgmt-tools] [PATCH][virt-viewer][MAN] typo In-Reply-To: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> References: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> Message-ID: <20080408103611.GC4783@amd.home.annexia.org> On Tue, Apr 08, 2008 at 10:36:11AM +0900, Atsushi SAKAI wrote: > Hi, Dan > > Fix man on virt-viewer. > (--help option) I forwarded that one to the gtk-vnc-devel list where I think virt-viewer patches are supposed to go. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From apevec at redhat.com Tue Apr 8 11:32:23 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 08 Apr 2008 13:32:23 +0200 Subject: [et-mgmt-tools] [PATCH][virt-manager] fix Delete button visibility Message-ID: <47FB57C7.7000905@redhat.com> fix Delete button visibility change Delete button visibility if selected vm is started/stopped, in the same way it's changed upon row selection Signed-off-by: Alan Pevec --- a/src/virtManager/manager.py Thu Apr 03 19:12:20 2008 -0400 +++ b/src/virtManager/manager.py Tue Apr 08 13:11:13 2008 +0200 @@ -475,8 +475,16 @@ class vmmManager(gobject.GObject): del self.rows[vm.get_uuid()] break - if missing and wanted: - self._append_vm(model, vm, vm.get_connection()) + if wanted: + if missing: + self._append_vm(model, vm, vm.get_connection()) + elif vm.get_uuid() == self.current_vmuuid(): + if vm.is_active(): + self.window.get_widget("vm-delete").set_sensitive(False) + else: + self.window.get_widget("vm-delete").set_sensitive(True) + + def vm_resources_sampled(self, vm): From lhaig at haigmail.com Tue Apr 8 13:03:24 2008 From: lhaig at haigmail.com (lhaig-haigmail.com) Date: Tue, 8 Apr 2008 09:03:24 -0400 Subject: [et-mgmt-tools] Packaging virt-manager for forsightlinux In-Reply-To: <20080408103353.GA4783@amd.home.annexia.org> References: <20080408103353.GA4783@amd.home.annexia.org> Message-ID: <4ab4fac8bd46d0842ebb685cfc3eb922@haigmail.com> Thank Richard, I sent that a while ago and then found out that virsh does not exist. I will have to package that first :-) So I will get back to you on that Thanks for the help Lance On Tue, 8 Apr 2008 11:33:53 +0100, "Richard W.M. Jones" wrote: > On Sun, Apr 06, 2008 at 01:16:13PM +0100, Lance Haig wrote: >> I am trying to package virt-manager, virtinst and virt-viewer for > foresight >> linux. > > (As background, Foresight Linux uses the Conary package manager as > written by rPath: > http://en.wikipedia.org/wiki/Conary_%28package_manager%29) > >> I have been able to package virt-manager and virtinst. When I run >> virt-manager and try to connect to the local machine with kvm/qemu >> installed it gives me a traceback about libvirtd not running. >> >> I have libvirt installed as I can run kvm/qemu machines without much > fuss. > > Before launching into virt-manager, start with the basics. What do > these commands say? > > virsh list > virsh list --all > virsh -c qemu:///system list > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into Xen guests. > http://et.redhat.com/~rjones/virt-p2v > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From berrange at redhat.com Tue Apr 8 13:05:12 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Apr 2008 14:05:12 +0100 Subject: [et-mgmt-tools] [PATCH][virt-viewer][MAN] typo In-Reply-To: <20080408103611.GC4783@amd.home.annexia.org> References: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> <20080408103611.GC4783@amd.home.annexia.org> Message-ID: <20080408130512.GA21948@redhat.com> On Tue, Apr 08, 2008 at 11:36:11AM +0100, Richard W.M. Jones wrote: > On Tue, Apr 08, 2008 at 10:36:11AM +0900, Atsushi SAKAI wrote: > > Hi, Dan > > > > Fix man on virt-viewer. > > (--help option) > > I forwarded that one to the gtk-vnc-devel list where I think > virt-viewer patches are supposed to go. Actually virt-viewer is a standalone app separate from GTK-VNC, so this list is the right place. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Tue Apr 8 15:13:44 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 Apr 2008 11:13:44 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <20080408025310.GB16017@sliderule.msquared.net.au> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <20080408025310.GB16017@sliderule.msquared.net.au> Message-ID: <47FB8BA8.5000709@redhat.com> Msquared wrote: > On Mon, Apr 07, 2008 at 12:13:46PM -0400, Michael DeHaan wrote: > > >> Ideally one wouldn't be assigning specific packages to specific systems, >> as the point of a profile is to make a configuration available to all >> things that look "like" something. Can you explain your use case for >> assigning specific packages to specific systems? >> > > I can: I have two 'workstations' that run on power from a single UPS. > Only one of them, however, is actually connected to the UPS' > communications port - the other one talks via TCP/IP to the first to > determine UPS status. > > All workstations have nut-client installed, but only the workstation > connected to the UPS' communications port has nut installed. > > Granted, I could probably have a 'with-ups' profile based on the standard > workstation profile, but it hardly seems worth it to me. :-) > > Actually, relevant question: If I have a 'workstation-with-ups' profile > based on a 'workstation' profile, and add packages to the 'workstation' > profile, will the packages also be automatically added to the > 'workstation-with-ups' profile? > Currently it's all based on the kickstart template, so there's not anything there that explicitly knows what a "package" is. If we do implement something like what we've been talking about, you could possibly achieve that behavior with something like %packages SNIPPET::profile_packages_list SNIPPET::system_packages_list And that would source files from /var/lib/cobbler/snippets/profiles/profile_packages_list/$profile_name /var/lib/cobbler/snippets/systems/system_packages_list/$system_name It would also be looking in a few other directories, but as those files would not exist, it would not find those. Would that be workable? It seems cleaner than making Cobbler grok what a "package" is, and also tends to work better when supporting non-kickstart distros (as they could still then utilize the expanded template system in a generic way). (It's also technically possible to have the kickstart detect that the kickstart template describes a system and put in some logic into the template to add "nut" for certain systems... so there are lots of ways to do it) --Michael From ssklar at stanford.edu Tue Apr 8 16:11:22 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Tue, 8 Apr 2008 09:11:22 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <47FA62B3.2050309@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> Message-ID: On Apr 7, 2008, at 11:06 AM, Michael DeHaan wrote: > > What if we changed the semantics of... > > SNIPPET::foosball > > which would now be smart and would pull one of the following, > whichever exists first: > > /var/lib/cobbler/snippets/system/foosball/$system_name > /var/lib/cobbler/snippets/profile/foosball/$profile_name > /var/lib/cobbler/snippets/distro/foosball/$distro_name > /var/lib/cobbler/snippets/foosball > > whichever was found first. > > I think this is what you're getting at and could be done fairly > cleanly without being package specific. > > Of course the stock install would lay down none of these paths > except the directories and this would largely be just documented > if you decide to use it (on the Wiki). I think that would be perfect! Thanks! -s- From mdehaan at redhat.com Tue Apr 8 17:20:59 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 Apr 2008 13:20:59 -0400 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.8.3 Message-ID: <47FBA97B.4030804@redhat.com> Cobbler 0.8.3 is a release to fix items found on the 0.8.X branch while work continues on 0.9.X/1.0. From the changelog: - Make createrepo run for local cobbler reposync invocations as needed - fix WebUI documentation URL - fix bug in /etc/cobbler/modules.conf regarding pluggable authn/z - fix default flags for yumdownloader - fix for RHEL 4u6 DVD/tree import x86_64 arch detection - fix dnsmasq template to point at the correct hosts file - force all names to be alphanumeric The 0.9.X branch is coming along well. The plan is to work on it for another month or so and then have a test release. 1.0 should be available in June. So far Cobbler 0.9.X includes: - the ownership module (mentioned on list) - patch to allow yumopts to override gpgcheck - Lots of authn/authz improvements - LDAP authentication support - ability to delete kopts/ksmeta from the command line - ability to send the hostname via ISC dhcpd - support for the new default tftpboot location /var/lib/tftpboot in F9 (discovered from xinetd) - WebUI now has a checkbox for deleting child objects - Seperate semantics for "add" vs "edit", and a --no-clobber option to add to allow "add or edit" behavior. - Detection/prevention for duplicate IP/MAC info Koan 0.8.2 will be released at the same time, which right now also includes: - VMware support - changes to work with the new version of livecd creator (for Cobbler LiveCD) Still on the list for Cobbler 0.9.X/1.0 - Refine/test kerberos support - Fixing up the kickstart editor - Update templates to use %end to avoid warning from validateks - Better status tracking (finally!) - Smarter kickstart snippets, as mentioned on the list recently - ... other neat stuff ... The source RPM is available now at http://cobbler.et.redhat.com/download and will be pushed out to the mirrors shortly for EL-4, EL-5, F-7, F-8, and devel (F-9). Thanks to everyone who has contributed ideas, patches, testing, and feedback! --Michael From jlaska at redhat.com Tue Apr 8 18:26:53 2008 From: jlaska at redhat.com (James Laska) Date: Tue, 08 Apr 2008 18:26:53 +0000 Subject: [et-mgmt-tools] virtinst/ImageFetcher.patch Message-ID: <1207679213.23998.25.camel@flatline> Greetings, Spoke with Dan Berrang? on irc about using virtinst/ImageFetcher.py for use in the snake project. I've basically copied the contents with a few tweaks. Dan suggested sending the patch to et-mgmt-tools at redhat.com for comments/thoughts. The patch consists of 3 main hunks: 1 Split acquireFile() into 2 new methods > saveFile() - does what acquireFile() does now, downloads file, writes contents to disk, returns its path > loadFile() - downloads file and returns file contents 2 MountedImageFetcher().prepareLocation() will check if the requested server:/path is already mounted > Supporting mtab code can be found at http://git.fedorahosted.org/git/snake?p=snake;a=blob;f=snake/util.py;h=5815e28ce98e3a5c9dd0b0ec7b380cc05fd39d6c;hb=HEAD 3 LocalImageFetcher()._acquireFile() will use grabber.urlopen so that it can make use of of the progress callback when copying files via saveTemp() calls. Hope this is helpful. Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: ImageFetcher.patch Type: text/x-patch Size: 6404 bytes Desc: not available URL: From apevec at redhat.com Tue Apr 8 19:17:32 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 08 Apr 2008 21:17:32 +0200 Subject: [et-mgmt-tools] [PATCH][virt-manager] fix Delete button visibility In-Reply-To: <47FB57C7.7000905@redhat.com> References: <47FB57C7.7000905@redhat.com> Message-ID: <47FBC4CC.9040704@redhat.com> Alan Pevec wrote: > fix Delete button visibility > > change Delete button visibility if selected vm is started/stopped, in > the same way it's changed upon row selection Cole pointed out this is already fixed by http://hg.et.redhat.com/virt/applications/virt-manager--devel?cs=dc9c723e13ff and it's in 0.5.4 From berrange at redhat.com Tue Apr 8 19:17:46 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Apr 2008 20:17:46 +0100 Subject: [et-mgmt-tools] [PATCH][virt-viewer][MAN] typo In-Reply-To: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> References: <200804080136.m381aBkF013426@fjmscan503.ms.jp.fujitsu.com> Message-ID: <20080408191746.GB6560@redhat.com> On Tue, Apr 08, 2008 at 10:36:11AM +0900, Atsushi SAKAI wrote: > Hi, Dan > > Fix man on virt-viewer. > (--help option) Thanks, I have applied this Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Tue Apr 8 19:24:27 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 8 Apr 2008 20:24:27 +0100 Subject: [et-mgmt-tools] virtinst/ImageFetcher.patch In-Reply-To: <1207679213.23998.25.camel@flatline> References: <1207679213.23998.25.camel@flatline> Message-ID: <20080408192427.GC6560@redhat.com> On Tue, Apr 08, 2008 at 06:26:53PM +0000, James Laska wrote: > Greetings, > > Spoke with Dan Berrang? on irc about using virtinst/ImageFetcher.py for > use in the snake project. I've basically copied the contents with a few > tweaks. Dan suggested sending the patch to et-mgmt-tools at redhat.com for > comments/thoughts. The patch consists of 3 main hunks: > > 1 Split acquireFile() into 2 new methods > > saveFile() - does what acquireFile() does now, downloads file, > writes contents to disk, returns its path > > loadFile() - downloads file and returns file contents > > 2 MountedImageFetcher().prepareLocation() will check if the requested > server:/path is already mounted > > Supporting mtab code can be found at > http://git.fedorahosted.org/git/snake?p=snake;a=blob;f=snake/util.py;h=5815e28ce98e3a5c9dd0b0ec7b380cc05fd39d6c;hb=HEAD > > 3 LocalImageFetcher()._acquireFile() will use grabber.urlopen so that > it can make use of of the progress callback when copying files via > saveTemp() calls. There's a couple of chunks in this paatch which directly depend on snake. eg - ret = subprocess.call(cmd) + ret = snake.util.pcall(cmd, stderr=open('/dev/null', 'w')) Aside from that, it looks reasonable. Dan -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jlaska at redhat.com Tue Apr 8 19:38:19 2008 From: jlaska at redhat.com (James Laska) Date: Tue, 08 Apr 2008 19:38:19 +0000 Subject: [et-mgmt-tools] virtinst/ImageFetcher.patch In-Reply-To: <20080408192427.GC6560@redhat.com> References: <1207679213.23998.25.camel@flatline> <20080408192427.GC6560@redhat.com> Message-ID: <1207683499.23998.35.camel@flatline> On Tue, 2008-04-08 at 20:24 +0100, Daniel P. Berrange wrote: > On Tue, Apr 08, 2008 at 06:26:53PM +0000, James Laska wrote: > > Greetings, > > > > Spoke with Dan Berrang? on irc about using virtinst/ImageFetcher.py for > > use in the snake project. I've basically copied the contents with a few > > tweaks. Dan suggested sending the patch to et-mgmt-tools at redhat.com for > > comments/thoughts. The patch consists of 3 main hunks: > > > > 1 Split acquireFile() into 2 new methods > > > saveFile() - does what acquireFile() does now, downloads file, > > writes contents to disk, returns its path > > > loadFile() - downloads file and returns file contents > > > > 2 MountedImageFetcher().prepareLocation() will check if the requested > > server:/path is already mounted > > > Supporting mtab code can be found at > > http://git.fedorahosted.org/git/snake?p=snake;a=blob;f=snake/util.py;h=5815e28ce98e3a5c9dd0b0ec7b380cc05fd39d6c;hb=HEAD > > > > 3 LocalImageFetcher()._acquireFile() will use grabber.urlopen so that > > it can make use of of the progress callback when copying files via > > saveTemp() calls. > > There's a couple of chunks in this paatch which directly depend on > snake. eg > > - ret = subprocess.call(cmd) > + ret = snake.util.pcall(cmd, stderr=open('/dev/null', 'w')) > > Aside from that, it looks reasonable. subprocess doesn't exist on RHEL3 and RHEL4, so I had to provide a helper to fill in the blanks in those environments. Additionally, there is some snake.util.get_mtab() methods that would need definition if that chunk is used. Thanks, James -- ========================================== James Laska -- jlaska at redhat.com Quality Engineering -- Red Hat, Inc. ========================================== From mdehaan at redhat.com Tue Apr 8 20:29:39 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 Apr 2008 16:29:39 -0400 Subject: [et-mgmt-tools] [ANNOUNCE] Cobbler 0.8.3 In-Reply-To: <47FBA97B.4030804@redhat.com> References: <47FBA97B.4030804@redhat.com> Message-ID: <47FBD5B3.7010502@redhat.com> Michael DeHaan wrote: > Cobbler 0.8.3 is a release to fix items found on the 0.8.X branch > while work continues on 0.9.X/1.0. If you've already downloaded this, make sure you re-download 0.8.3-3 from the website and upgrade to that as my "naming" filter was a bit too strict (it needed to tolerate "_"'s). Yum updates in Fedora/EPEL will get 0.8.3-3 automatically. --Michael From cranfill at imageworks.com Tue Apr 8 20:50:52 2008 From: cranfill at imageworks.com (Jennifer Cranfill) Date: Tue, 08 Apr 2008 13:50:52 -0700 Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? Message-ID: <47FBDAAC.7040908@imageworks.com> Last night I had to do the following procedure with Cobbler to boot a remote server into rescue mode. I'm wondering if any one else thinks it would be worthwhile to incorporate a rescue mode feature into Cobbler's handling of pxe files? Or is there already one that I don't know about? We maintain a number of remote critical servers, and I think it would be useful, especially as in the procedure below I had to be careful that no one else rebooted the server or ran "cobbler sync" while I was updating the pxe file. Also, it might be possible to automate more of the rescue boot. 1) cobbler system edit --name= --netboot-enabled=y; cobbler sync 2) cd /tftpboot/pxelinux.cfg 3) Edit the file corresponding to the MAC of . Take everything out of the append line except the initrd and add "rescue", like so: append rescue initrd=/images/51x64/initrd.img 4) Reboot 5) When the system boots, it will ask you for language and keyboard and then it will ask you for the location of the *rescue* media. Just give it the http to the normal install files for the distro matching the initrd. 6) cobbler system edit --name= --netboot-enabled=n; cobbler sync I took the idea from this Red Hat page: http://www.redhatmagazine.com/2007/07/05/solutions-from-the-road-red-hat-enterprise-linux-rescue-mode-over-pxe-part-i/ I'd be happy to help with the code, but not sure the right way to architect it, perhaps some variant of netboot-enabled? Thanks for your consideration! -- Jennifer Cranfill Systems Engineer Sony Pictures Imageworks cranfill at imageworks.com From mdehaan at redhat.com Tue Apr 8 21:07:58 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 Apr 2008 17:07:58 -0400 Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? In-Reply-To: <47FBDAAC.7040908@imageworks.com> References: <47FBDAAC.7040908@imageworks.com> Message-ID: <47FBDEAE.7090609@redhat.com> Jennifer Cranfill wrote: > Last night I had to do the following procedure with Cobbler to boot a > remote server into rescue mode. I'm wondering if any one else thinks > it would be worthwhile to incorporate a rescue mode feature into > Cobbler's handling of pxe files? Or is there already one that I don't > know about? Could we create "rescue" profiles automatically when we do imports? It would just be a different profile ending in "-rescue" that would just have "--kopts=rescue" added. Example "DistroName-i386-rescue". The other thing we /might/ want to do is set up a kickstart template for that profile (and assign it) that can be used to feed the rescue image the media information, so you don't have to enter that in manually. Presumably that could all be done with modifications to action_import.py > > We maintain a number of remote critical servers, and I think it would > be useful, especially as in the procedure below I had to be careful > that no one else rebooted the server or ran "cobbler sync" while I was > updating the pxe file. Also, it might be possible to automate more of > the rescue boot. > > 1) cobbler system edit --name= --netboot-enabled=y; cobbler sync > 2) cd /tftpboot/pxelinux.cfg > 3) Edit the file corresponding to the MAC of . Take > everything out of the append line except the initrd and add "rescue", > like so: > append rescue initrd=/images/51x64/initrd.img > 4) Reboot > 5) When the system boots, it will ask you for language and keyboard > and then it will ask you for the location of the *rescue* media. Just > give it the http to the normal install files for the distro matching > the initrd. > 6) cobbler system edit --name= --netboot-enabled=n; cobbler sync > > I took the idea from this Red Hat page: > http://www.redhatmagazine.com/2007/07/05/solutions-from-the-road-red-hat-enterprise-linux-rescue-mode-over-pxe-part-i/ > > If we do something like having a rescue profile, it's just: cobbler system edit --name=server1 --profile=F-9-i386-rescue --netboot-enabled=1 # fix system cobbler system edit --name=server1 --profile=originalname --netboot-enabled=0 The one thing that requires is knowing the proper rescue profile for server1, so it's possible we could add a --rescueprofile= to the system and also have a --rescuemode=1/0 like --netboot-enabled if you think that's useful. That could be interesting. That workflow might be like: cobbler system edit --name=server1 --rescuemode (rescuemode could actually set netboot-enabled to 1 for simplicity) cobbler system edit --name =server1 --workingmode (this could set netboot enabled back) > I'd be happy to help with the code, but not sure the right way to > architect it, perhaps some variant of netboot-enabled? Sounds great! Yeah I think the first step is making the rescue profiles when imports are done, the second stage is probably something like netboot-enabled (as above) if you like the workflow? Is that close? I think I'd start taking a look at import for starters -- and if that's not all that's needed we can work it from there. Cool idea! > > Thanks for your consideration! > > -- > Jennifer Cranfill > Systems Engineer > Sony Pictures Imageworks > cranfill at imageworks.com > > _______________________________________________ > 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 Apr 8 21:21:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 08 Apr 2008 17:21:33 -0400 Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? In-Reply-To: <47FBDEAE.7090609@redhat.com> References: <47FBDAAC.7040908@imageworks.com> <47FBDEAE.7090609@redhat.com> Message-ID: <47FBE1DD.3060008@redhat.com> Michael DeHaan wrote: > Jennifer Cranfill wrote: >> Last night I had to do the following procedure with Cobbler to boot a >> remote server into rescue mode. I'm wondering if any one else thinks >> it would be worthwhile to incorporate a rescue mode feature into >> Cobbler's handling of pxe files? Or is there already one that I don't >> know about? > > Could we create "rescue" profiles automatically when we do imports? > It would just be a different profile ending in "-rescue" that would > just have "--kopts=rescue" added. Example "DistroName-i386-rescue". > The other thing we /might/ want to do is set up a kickstart template > for that profile (and assign it) that can be used to feed the rescue > image the media information, so you don't have to enter that in > manually. > Presumably that could all be done with modifications to action_import.py > >> >> We maintain a number of remote critical servers, and I think it would >> be useful, especially as in the procedure below I had to be careful >> that no one else rebooted the server or ran "cobbler sync" while I >> was updating the pxe file. Also, it might be possible to automate >> more of the rescue boot. >> >> 1) cobbler system edit --name= --netboot-enabled=y; cobbler >> sync >> 2) cd /tftpboot/pxelinux.cfg >> 3) Edit the file corresponding to the MAC of . Take >> everything out of the append line except the initrd and add "rescue", >> like so: >> append rescue initrd=/images/51x64/initrd.img >> 4) Reboot >> 5) When the system boots, it will ask you for language and keyboard >> and then it will ask you for the location of the *rescue* media. Just >> give it the http to the normal install files for the distro matching >> the initrd. >> 6) cobbler system edit --name= --netboot-enabled=n; cobbler >> sync >> >> I took the idea from this Red Hat page: >> http://www.redhatmagazine.com/2007/07/05/solutions-from-the-road-red-hat-enterprise-linux-rescue-mode-over-pxe-part-i/ >> >> > > If we do something like having a rescue profile, it's just: > > cobbler system edit --name=server1 --profile=F-9-i386-rescue > --netboot-enabled=1 > # fix system > cobbler system edit --name=server1 --profile=originalname > --netboot-enabled=0 > > The one thing that requires is knowing the proper rescue profile for > server1, so it's possible we could add a --rescueprofile= to the > system and also have a --rescuemode=1/0 like --netboot-enabled if you > think that's useful. That could be interesting. > > That workflow might be like: > > cobbler system edit --name=server1 --rescuemode (rescuemode could > actually set netboot-enabled to 1 for simplicity) > cobbler system edit --name =server1 --workingmode (this could set > netboot enabled back) >> I'd be happy to help with the code, but not sure the right way to >> architect it, perhaps some variant of netboot-enabled? > > Sounds great! > > Yeah I think the first step is making the rescue profiles when imports > are done, the second stage is probably something like > netboot-enabled (as above) if you like the workflow? Is that close? > > I think I'd start taking a look at import for starters -- and if > that's not all that's needed we can work it from there. > Cool idea! > > > >> >> Thanks for your consideration! >> >> -- >> Jennifer Cranfill >> Systems Engineer >> Sony Pictures Imageworks >> cranfill at imageworks.com >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > To clarify syntax a bit more and see if we're on the same page, how about the following? cobbler import --name=F9A --mirror=path # automatically creates F9A-i386, F9A-i386-xen, F9A-i386-rescue as both distros and profiles (action_import.py) # automatically does the equivalent of "cobbler profile edit --name=F9A-i386 --rescueprofile=F9A-i386-rescue" Basically the above would allow any given profile to store the name of /another/ profile that is used for rescue mode. You may ask "why isn't rescue mode part of the distro", and the answer here is that if it's a profile we can take advantage of it also showing up in PXE menus automatically. System syntax could also look like this: cobbler system edit --name=F9A --rescuemode [implies --netboot-enabled=1] cobbler system edit --name=F9A --workingmode [--netboot-enabled=1/0] The commands --rescuemode would toggle netboot-enabled and temporarily set up PXE to point to the rescue profile. The command --workingmode would set it back, but at no time do you have to remember what the proper rescue distro is for a given system -- because it asks the profile for that info. This would be something that would be really easy to incorporate into the web interface as well -- as it would just be a couple of checkboxes. That eventually involves also modifying files like action_sync.py and modules/cli_system.py and item_system.py/item_profile.py -- though nothing too invasive. (And I can help on this...) --Michael From cranfill at imageworks.com Tue Apr 8 22:40:09 2008 From: cranfill at imageworks.com (Jennifer Cranfill) Date: Tue, 08 Apr 2008 15:40:09 -0700 Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? In-Reply-To: <47FBE1DD.3060008@redhat.com> References: <47FBDAAC.7040908@imageworks.com> <47FBDEAE.7090609@redhat.com> <47FBE1DD.3060008@redhat.com> Message-ID: <47FBF449.7090603@imageworks.com> Michael DeHaan wrote: > Michael DeHaan wrote: > > > > Could we create "rescue" profiles automatically when we do imports? > > It would just be a different profile ending in "-rescue" that would > > just have "--kopts=rescue" added. Example "DistroName-i386-rescue". > > The other thing we /might/ want to do is set up a kickstart template > > for that profile (and assign it) that can be used to feed the rescue > > image the media information, so you don't have to enter that in > > manually. > > Presumably that could all be done with modifications to action_import.py > > > > > > If we do something like having a rescue profile, it's just: > > > > cobbler system edit --name=server1 --profile=F-9-i386-rescue > > --netboot-enabled=1 > > # fix system > > cobbler system edit --name=server1 --profile=originalname > > --netboot-enabled=0 > > > > The one thing that requires is knowing the proper rescue profile for > > server1, so it's possible we could add a --rescueprofile= to the > > system and also have a --rescuemode=1/0 like --netboot-enabled if you > > think that's useful. That could be interesting. > > > > That workflow might be like: > > > > cobbler system edit --name=server1 --rescuemode (rescuemode could > > actually set netboot-enabled to 1 for simplicity) > > cobbler system edit --name =server1 --workingmode (this could set > > netboot enabled back) > > To clarify syntax a bit more and see if we're on the same page, how > about the following? > > cobbler import --name=F9A --mirror=path > # automatically creates F9A-i386, F9A-i386-xen, F9A-i386-rescue as both > distros and profiles (action_import.py) > # automatically does the equivalent of "cobbler profile edit > --name=F9A-i386 --rescueprofile=F9A-i386-rescue" > > Basically the above would allow any given profile to store the name of > /another/ profile that is used for rescue mode. > You may ask "why isn't rescue mode part of the distro", and the answer > here is that if it's a profile we can take advantage > of it also showing up in PXE menus automatically. > > System syntax could also look like this: > > cobbler system edit --name=F9A --rescuemode [implies --netboot-enabled=1] > cobbler system edit --name=F9A --workingmode [--netboot-enabled=1/0] > > The commands --rescuemode would toggle netboot-enabled and temporarily > set up PXE to point to the rescue profile. > The command --workingmode would set it back, but at no time do you have > to remember what the proper rescue distro > is for a given system -- because it asks the profile for that info. > > This would be something that would be really easy to incorporate into > the web interface as well -- as it would just be a couple of checkboxes. > > That eventually involves also modifying files like action_sync.py and > modules/cli_system.py and item_system.py/item_profile.py -- though > nothing too invasive. (And I can help on this...) That sounds great to me! I like the idea of putting it in the profile. I'll start taking a look at the code. Thanks Michael! --Jennifer From Pablo.Iranzo at redhat.com Wed Apr 9 00:44:47 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Wed, 9 Apr 2008 02:44:47 +0200 (CEST) Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? (MEMTEST) In-Reply-To: <47FBF449.7090603@imageworks.com> References: <47FBDAAC.7040908@imageworks.com> <47FBDEAE.7090609@redhat.com> <47FBE1DD.3060008@redhat.com> <47FBF449.7090603@imageworks.com> Message-ID: Hi, for your review: Based on talk with Michael on irc, the ability to create menus for memtest if installed arised, so here is the patch attached for cobbler 0.9x. This is for ticket #94 @ trac If there is any /boot/memtest* file, it will copy to /tftpboot/ (or whatever the location based on cobbler variables) and then create menu entries named as "memtest*" filename with kernel "filename". I didn't wrote a "delete" for copied memtest's for this patch as even, an old copy of memtest could be useful, if you think that deletion should be included, please, start blaming :) Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Tue, 8 Apr 2008, Jennifer Cranfill wrote: > Michael DeHaan wrote: > > Michael DeHaan wrote: > > > > > > Could we create "rescue" profiles automatically when we do imports? > > > It would just be a different profile ending in "-rescue" that would > > > just have "--kopts=rescue" added. Example "DistroName-i386-rescue". > > > The other thing we /might/ want to do is set up a kickstart template > > > for that profile (and assign it) that can be used to feed the rescue > > > image the media information, so you don't have to enter that in > > > manually. > > > Presumably that could all be done with modifications to action_import.py > > > > > > > > > If we do something like having a rescue profile, it's just: > > > > > > cobbler system edit --name=server1 --profile=F-9-i386-rescue > > > --netboot-enabled=1 > > > # fix system > > > cobbler system edit --name=server1 --profile=originalname > > > --netboot-enabled=0 > > > > > > The one thing that requires is knowing the proper rescue profile for > > > server1, so it's possible we could add a --rescueprofile= to the > > > system and also have a --rescuemode=1/0 like --netboot-enabled if you > > > think that's useful. That could be interesting. > > > > > > That workflow might be like: > > > > > > cobbler system edit --name=server1 --rescuemode (rescuemode could > > > actually set netboot-enabled to 1 for simplicity) > > > cobbler system edit --name =server1 --workingmode (this could set > > > netboot enabled back) > > > > To clarify syntax a bit more and see if we're on the same page, how > > about the following? > > > > cobbler import --name=F9A --mirror=path > > # automatically creates F9A-i386, F9A-i386-xen, F9A-i386-rescue as both > > distros and profiles (action_import.py) > > # automatically does the equivalent of "cobbler profile edit > > --name=F9A-i386 --rescueprofile=F9A-i386-rescue" > > > > Basically the above would allow any given profile to store the name of > > /another/ profile that is used for rescue mode. > > You may ask "why isn't rescue mode part of the distro", and the answer > > here is that if it's a profile we can take advantage > > of it also showing up in PXE menus automatically. > > > > System syntax could also look like this: > > > > cobbler system edit --name=F9A --rescuemode [implies --netboot-enabled=1] > > cobbler system edit --name=F9A --workingmode [--netboot-enabled=1/0] > > > > The commands --rescuemode would toggle netboot-enabled and temporarily > > set up PXE to point to the rescue profile. > > The command --workingmode would set it back, but at no time do you have > > to remember what the proper rescue distro > > is for a given system -- because it asks the profile for that info. > > > > This would be something that would be really easy to incorporate into > > the web interface as well -- as it would just be a couple of checkboxes. > > > > That eventually involves also modifying files like action_sync.py and > > modules/cli_system.py and item_system.py/item_profile.py -- though > > nothing too invasive. (And I can help on this...) > > That sounds great to me! I like the idea of putting it in the profile. > I'll start taking a look at the code. Thanks Michael! > > --Jennifer > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- A non-text attachment was scrubbed... Name: memtest.diff Type: text/x-diff Size: 2559 bytes Desc: URL: From Pablo.Iranzo at redhat.com Wed Apr 9 00:58:50 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Wed, 9 Apr 2008 02:58:50 +0200 (CEST) Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? (MEMTEST) In-Reply-To: References: <47FBDAAC.7040908@imageworks.com> <47FBDEAE.7090609@redhat.com> <47FBE1DD.3060008@redhat.com> <47FBF449.7090603@imageworks.com> Message-ID: Hi If anyone interested in previous memtest removals for patch is attached (instead of the preceding patch) Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Wed, 9 Apr 2008, Pablo Iranzo G?mez wrote: > > Hi, for your review: > > Based on talk with Michael on irc, the ability to create menus > for memtest if installed arised, so here is the patch attached for cobbler > 0.9x. This is for ticket #94 @ trac > > If there is any /boot/memtest* file, it will copy to /tftpboot/ > (or whatever the location based on cobbler variables) and then create menu > entries named as "memtest*" filename with kernel "filename". > > I didn't wrote a "delete" for copied memtest's for this patch as > even, an old copy of memtest could be useful, if you think that deletion > should be included, please, start blaming :) > > Regards > Pablo > > > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? > > On Tue, 8 Apr 2008, Jennifer Cranfill wrote: > > > Michael DeHaan wrote: > > > Michael DeHaan wrote: > > > > > > > > Could we create "rescue" profiles automatically when we do imports? > > > > It would just be a different profile ending in "-rescue" that would > > > > just have "--kopts=rescue" added. Example "DistroName-i386-rescue". > > > > The other thing we /might/ want to do is set up a kickstart template > > > > for that profile (and assign it) that can be used to feed the rescue > > > > image the media information, so you don't have to enter that in > > > > manually. > > > > Presumably that could all be done with modifications to action_import.py > > > > > > > > > > > > If we do something like having a rescue profile, it's just: > > > > > > > > cobbler system edit --name=server1 --profile=F-9-i386-rescue > > > > --netboot-enabled=1 > > > > # fix system > > > > cobbler system edit --name=server1 --profile=originalname > > > > --netboot-enabled=0 > > > > > > > > The one thing that requires is knowing the proper rescue profile for > > > > server1, so it's possible we could add a --rescueprofile= to the > > > > system and also have a --rescuemode=1/0 like --netboot-enabled if you > > > > think that's useful. That could be interesting. > > > > > > > > That workflow might be like: > > > > > > > > cobbler system edit --name=server1 --rescuemode (rescuemode could > > > > actually set netboot-enabled to 1 for simplicity) > > > > cobbler system edit --name =server1 --workingmode (this could set > > > > netboot enabled back) > > > > > > To clarify syntax a bit more and see if we're on the same page, how > > > about the following? > > > > > > cobbler import --name=F9A --mirror=path > > > # automatically creates F9A-i386, F9A-i386-xen, F9A-i386-rescue as both > > > distros and profiles (action_import.py) > > > # automatically does the equivalent of "cobbler profile edit > > > --name=F9A-i386 --rescueprofile=F9A-i386-rescue" > > > > > > Basically the above would allow any given profile to store the name of > > > /another/ profile that is used for rescue mode. > > > You may ask "why isn't rescue mode part of the distro", and the answer > > > here is that if it's a profile we can take advantage > > > of it also showing up in PXE menus automatically. > > > > > > System syntax could also look like this: > > > > > > cobbler system edit --name=F9A --rescuemode [implies --netboot-enabled=1] > > > cobbler system edit --name=F9A --workingmode [--netboot-enabled=1/0] > > > > > > The commands --rescuemode would toggle netboot-enabled and temporarily > > > set up PXE to point to the rescue profile. > > > The command --workingmode would set it back, but at no time do you have > > > to remember what the proper rescue distro > > > is for a given system -- because it asks the profile for that info. > > > > > > This would be something that would be really easy to incorporate into > > > the web interface as well -- as it would just be a couple of checkboxes. > > > > > > That eventually involves also modifying files like action_sync.py and > > > modules/cli_system.py and item_system.py/item_profile.py -- though > > > nothing too invasive. (And I can help on this...) > > > > That sounds great to me! I like the idea of putting it in the profile. > > I'll start taking a look at the code. Thanks Michael! > > > > --Jennifer > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > -------------- next part -------------- A non-text attachment was scrubbed... Name: memtest-removal.diff Type: text/x-diff Size: 2804 bytes Desc: URL: From ghoneycutt at hq.speakeasy.net Wed Apr 9 03:39:23 2008 From: ghoneycutt at hq.speakeasy.net (Garrett Honeycutt) Date: Tue, 08 Apr 2008 20:39:23 -0700 Subject: [et-mgmt-tools] Help using the Cobbler API in triggers Message-ID: <47FC3A6B.5010308@hq.speakeasy.net> My goal is to access a variable within Cobbler, $hostname for example, and use that in a trigger that is run whenever a system is added. Below is some pseudo code to demonstrate my aim. os.system("/usr/local/sbin/dostuff.sh $hostname") Any help in that direction would be greatly appreciated. Thanks, -g -- Garrett Honeycutt Sr. Systems Engineer www.speakeasy.net Voice * Data * Managed Services From cranfill at imageworks.com Wed Apr 9 04:15:03 2008 From: cranfill at imageworks.com (Jennifer Cranfill) Date: Tue, 08 Apr 2008 21:15:03 -0700 Subject: [et-mgmt-tools] Help using the Cobbler API in triggers In-Reply-To: <47FC3A6B.5010308@hq.speakeasy.net> References: <47FC3A6B.5010308@hq.speakeasy.net> Message-ID: <47FC42C7.6080506@imageworks.com> Garrett Honeycutt wrote: > My goal is to access a variable within Cobbler, $hostname for example, > and use that in a trigger that is run whenever a system is added. Below > is some pseudo code to demonstrate my aim. > > os.system("/usr/local/sbin/dostuff.sh $hostname") Cobbler passes the name of the system as the first argument to the command. If your system name is the hostname, then in python you can just use something simple like: machine = sys.argv[1] If your system name is not the hostname then you can query the hostname of the system from Cobbler. Here is some python code I've been using: from cobbler import api cobbler_api = api.BootAPI() systems = cobbler_api.systems() box = systems.find(sys.argv[1]) I'm sure there are other (and probably better) ways as well. -- Jennifer Cranfill Systems Engineer Sony Pictures Imageworks From lippold at gmail.com Wed Apr 9 07:05:35 2008 From: lippold at gmail.com (Aaron Lippold) Date: Wed, 9 Apr 2008 03:05:35 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <47FA38FB.7060907@redhat.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> Message-ID: <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> Hi, If I am a little punchy here, don't mind me, just way too tired.... Sorry it took so long to get to responding really buys few days... What I am looking for is some additional levels to the profile templates which allow me to seperate out the code form the profile/template. It is close to some of the semantics that the Solaris Security Toolkit uses to break up how it does it system provisioning. It has a concept of Drivers - much like the cobber kickstart templates which define env settings, runtime vars, and which Finish scripts- the Finish scripts that do particular actions but rather than being a long bash script they are broken into smaller single chunks that can ge used across profiles and profile groups so that code is centralized. ( ks or bash or perl etc. ) This is where I started thinking about 'snipits' and 'groups of snipits'. This is also along the lines of Bastille breakdown as well. The basic problem is what I explain as "separation of implementation from interface" now this isn't totally accurate but I think for coders it gets the idea across. My ks templates shouldn't - i.e. technically cobbler cheetah profiles - hold real code just references to code that it will render in the final ks.cfg. Now a lot of we old end users just ignore this fact and put in #raw at the top of post and go our marry way. But I think stressing this separation could really expand the use cobber has in the overall system deployment and upkeep of those systems. Snipts and Groups An organization as sets of requirements - usually security or enterprise wide setting, files, etc. - that it uses to standardize the configuration management of its systems. These sets are usually organized by whatever organizational system they come up with but for the most part they are standard actions from the good old community best practices. ( set bootloader passwords, use sudo, install logging and setup, fixes known configuration issues with sendmail, copy over the standard MOTD, Company Banner etc. ) For my organization we have a whole set of "System Level" requiremetns, "Webserver", "Database" etc. and I can create a mapping easly from these requirements to snipits that take care of them. SNIPIT::set_bootloader_password SNIPIT::set_sshd_login_banner SNIPIT::disable_sendmail SNIPIT::setup_aide etc. Even better, if my sniptits take parameters, usually the "lock down and configuration" difference are only 644 vs 640 perms or what my password complexity requirments are for pam login or what the defualt file upload size for apache should be, etc. These "actions" aren't different - just what we put for the params of the action. Anther advantage is that some of these actions are different from distro to distro - just look at RHEL, Fedora and SuSE. The idea or spirit is the same but the implementation is different. === Grouping ==== These sniptits could then be group at a level above - since thier time of execution could matter - into a file simply... Although it looks like from the other thread that this is going the directory way, again, is this a mistake given that I don't really want do some things until the end and some right at the beginning or I really do want x to follow y to follow z. If we do it all by directory I would have to name all my snipits 1_... 2_... which would really make things not so elegant. snipit_groups/group1 set_bootloader_password set_password_retries set_passwd_min_uppper set_passwd_min_lower set_motd setup_aide setup_logrotate This way I can call either a set of actions or a single one in the cobbler kickstart template. ==== Kickstart Template ==== SNIPIT::_GROUP_ SNIPIT::small_thing SNIPIT::smaller_thing Another thing I find useful in this type of setup is that I can also make a mapping file : REG1:set_passwd_retries,set_passwd_min_upper,set_passwd_min_lower REG2:setup_aide REG3:set_motd which I can then use a little awk to parse and stick in logging of the actions that were taken on a system during a provisioning ( like we do with a ( set of actions... ) > mylog.txt in the %post most of the time. As an added benefit, if I also have a set of audit scripts that check for lockdown or settings that are out of wack and produces a list of those broken requirements ( REG1, REG23, REG45, REG655 are not set correctly ) its easy for me to make a quick script to run the set of sniptis that cover those items by parsing the mapping file. This could even be automated after a system update so that when I do update a package I run my "audit" scripts, parse the report, if the updates unset any of the things I set, will generate a quick script, include all the needed snippets and run them. Then run the "audit" again to verify that the system is back the way it was the day I provisioned it. To finish it all off, I could generate a nice report going "good" to "broken" to "fixed" to "good". I know I threw a lot out there but I think there are a few pages we could take from the Bastille and SST books that would really take cobbler to the next level. Most of the changes would be business, organization and execution process which I think could really expand the flexibility of the system. Let me know what you all think or just slap me around a bit ... Yours, Aaron On Mon, Apr 7, 2008 at 11:08 AM, Michael DeHaan wrote: > Aaron Lippold wrote: > > > Hi All, > > > > I did some chatting on the irc on this but wanted to post it to the list > > to get some feedback. > > > > I have some KS files already which setup and secure my systems to my > > organizations standards. I'd like to break up and generlize my processes and > > "scripts" - mainly in the post section - into smaller chunks to make it more > > flexible and manageable. I know I can do includes, snippets and triggers. > > The idea would be that I could have a "Core Set" of items that I could > > include into my ks template - OS::Lockdown - which would include / call a > > known set of actions. I could then develop other "sets" - MySQL, Apache, > > Oracle, etc. I am hoping that I could also then use those separable pieces > > after updates and patches to "reverify" the systems - assume I already have > > a set of scripts that I can run that will give me a list ( Item1, Item2, > > Item3) which require an action. With a little scripting and a "map" - flat > > txt with "Item1:OS::Boot::Action: - I could run each item that needs to be > > fixed again. > > > > I think this would be valueable because it would give the end user the > > ablity to divorce "interface from implamentation" as it were. It would allow > > you to use cobbler to also assist with maintaining the baseline etc. > > > > The question is which path to take. Thoughts, suggestions, "idiot, you > > can do that like this" would be appriciated :). > > > > Thanks, > > > > Aaron > > > > I'm not sure I understand what this would look like. Could you possibly > throw out some syntax of what that might look like in the template > file and how the files might be layed out behind the scenes? > > Right now snippets work as includes ... in fact, it's conceptually "just" > a Cheetah (Cobbler's templating language) include at this point. > > SNIPPET::foo just includes "/var/lib/cobbler/snippets/foo any time it is > present in the file. > > Can you explain further? > --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mad at vorsicht-bissig.de Wed Apr 9 09:18:47 2008 From: mad at vorsicht-bissig.de (mad at vorsicht-bissig.de) Date: Wed, 09 Apr 2008 11:18:47 +0200 Subject: [et-mgmt-tools] Create custom boot image for cobbler pxe boot Message-ID: <20080409091847.89610@gmx.net> Hi! I have a desktop PC I want to install with cobbler (Fedora Core 5) via network. The problem is, that the e1000 network card is to new for the pxeboot kernel from the FC5 CD. The cobbler boot runs without problems until it wants to download the kickstart file from the cobbler server. The error message is, that it can't find a network device. I already compiled a new e1000 module on an installed FC5 PC. The module works fine. Now how can I use the new module? I tried to update the initrd.img from my /tftpboot directory but that wouldn't work properly. Is there a possibility to create a new vmlinuz and initrd.img on the already installed PC that I can use for tftpboot? Or is there another possibilty to use the new e1000 module? Thanks in advance mad From tom at ng23.net Wed Apr 9 14:51:32 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 09 Apr 2008 15:51:32 +0100 Subject: [et-mgmt-tools] koan - rh7.3 - possible? Message-ID: <47FCD7F4.7070603@ng23.net> Hi I have some _really_ old OS installs that i am keen to refresh to our standard but they are RH7.3 - Does anyone know if there is a koan around for rh7.3 or even if it would work? Id prefer to not have to boot a koan ISO if at all possible. thanks From mdehaan at redhat.com Wed Apr 9 15:03:50 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 11:03:50 -0400 Subject: [et-mgmt-tools] Help using the Cobbler API in triggers In-Reply-To: <47FC42C7.6080506@imageworks.com> References: <47FC3A6B.5010308@hq.speakeasy.net> <47FC42C7.6080506@imageworks.com> Message-ID: <47FCDAD6.1040200@redhat.com> Jennifer Cranfill wrote: > Garrett Honeycutt wrote: >> My goal is to access a variable within Cobbler, $hostname for example, >> and use that in a trigger that is run whenever a system is added. Below >> is some pseudo code to demonstrate my aim. >> >> os.system("/usr/local/sbin/dostuff.sh $hostname") > > Cobbler passes the name of the system as the first argument to the > command. If your system name is the hostname, then in python you can > just use something simple like: > > machine = sys.argv[1] > > If your system name is not the hostname then you can query the > hostname of the system from Cobbler. Here is some python code I've > been using: > > from cobbler import api > cobbler_api = api.BootAPI() > systems = cobbler_api.systems() > box = systems.find(sys.argv[1]) > > I'm sure there are other (and probably better) ways as well. > > -- > Jennifer Cranfill > Systems Engineer > Sony Pictures Imageworks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Right! I added that example here -- https://fedorahosted.org/cobbler/wiki/CobblerTriggers -- so other people could find it when they were reading the docs. Thanks! --Michael From mdehaan at redhat.com Wed Apr 9 15:15:24 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 11:15:24 -0400 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <47FCD7F4.7070603@ng23.net> References: <47FCD7F4.7070603@ng23.net> Message-ID: <47FCDD8C.2050402@redhat.com> Tom Brown wrote: > Hi > > I have some _really_ old OS installs that i am keen to refresh to our > standard but they are RH7.3 - Does anyone know if there is a koan > around for rh7.3 or even if it would work? Id prefer to not have to > boot a koan ISO if at all possible. > > thanks > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Most likely not. It is expected to run as far back as RHEL3, though not before. However, you /might/ be able to get it to work if you rebuild the source rpm. I haven't tried it. (The live CD is of course still available, as is network boot) --Michael From mdehaan at redhat.com Wed Apr 9 15:24:10 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 11:24:10 -0400 Subject: [et-mgmt-tools] Create custom boot image for cobbler pxe boot In-Reply-To: <20080409091847.89610@gmx.net> References: <20080409091847.89610@gmx.net> Message-ID: <47FCDF9A.4080106@redhat.com> mad at vorsicht-bissig.de wrote: > Hi! > > I have a desktop PC I want to install with cobbler (Fedora Core 5) via network. The problem is, that the e1000 network card is to new for the pxeboot kernel from the FC5 CD. > > The cobbler boot runs without problems until it wants to download the kickstart file from the cobbler server. The error message is, that it can't find a network device. > > I already compiled a new e1000 module on an installed FC5 PC. The module works fine. Now how can I use the new module? > > I tried to update the initrd.img from my /tftpboot directory but that wouldn't work properly. Is there a possibility to create a new vmlinuz and initrd.img on the already installed PC that I can use for tftpboot? > > Or is there another possibilty to use the new e1000 module? > > Thanks in advance > mad > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > Can you repost this to kickstart-list at redhat.com? Basically you need to rebuild the installer initrd to include the e1000 driver, though this isn't quite the correct list for that as this is more of an installer question. Thanks! --Michael From ssklar at stanford.edu Wed Apr 9 15:27:34 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Wed, 9 Apr 2008 08:27:34 -0700 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> Message-ID: <4A4CBDA3-326E-4347-8796-453E00164EEA@stanford.edu> On Apr 9, 2008, at 12:05 AM, Aaron Lippold wrote: > <... snip ...> > Snipts and Groups > > An organization as sets of requirements - usually security or > enterprise wide setting, files, etc. - that it uses to standardize > the configuration management of its systems. These sets are usually > organized by whatever organizational system they come up with but > for the most part they are standard actions from the good old > community best practices. ( set bootloader passwords, use sudo, > install logging and setup, fixes known configuration issues with > sendmail, copy over the standard MOTD, Company Banner etc. ) These things really sound like you would want a configuration management tool (puppet, cfengine, etc.) to set those things after the kickstart is complete. What happens if you change the wording in your standard MOTD? Do your re-kickstart and install all of your systems so they get the new MOTD? <... snip ...> > > Although it looks like from the other thread that this is going the > directory way, again, is this a mistake given that I don't really > want do some things until the end and some right at the beginning or > I really do want x to follow y to follow z. If we do it all by > directory I would have to name all my snipits 1_... 2_... which > would really make things not so elegant. > > > snipit_groups/group1 > > set_bootloader_password > set_password_retries > set_passwd_min_uppper > set_passwd_min_lower > set_motd > setup_aide > setup_logrotate > > This way I can call either a set of actions or a single one in the > cobbler kickstart template. > > ==== Kickstart Template ==== > > SNIPIT::_GROUP_ > SNIPIT::small_thing > SNIPIT::smaller_thing I'm confused as to why you are assuming that files in a directory would have to be in alphabetical order. With the changes that have been proposed, using this example below, lets say "group1" is the name of a Cobbler profile that you are using. In your common /etc/cobbler/common.ks, you'd have something like: %post SNIPPET::post If you have the file: /var/lib/cobbler/snippets/group1/post, it could contain: SNIPPET::set_bootloader_password SNIPPET::set_password_retries SNIPPET::set_passwd_min_uppper SNIPPET::set_passwd_min_lower SNIPPET::set_motd SNIPPET::setup_aide SNIPPET::setup_logrotate ... and each of those separate snippet files would be included in the rendered kickstart. <... snip ...> > > I know I threw a lot out there but I think there are a few pages we > could take from the Bastille and SST books that would really take > cobbler to the next level. Most of the changes would be business, > organization and execution process which I think could really expand > the flexibility of the system. > > Let me know what you all think or just slap me around a bit ... No desire to "slap you around" :-) but I think your arguments against the proposed hierarchy are orthogonal to your proposals; neither really impacts the other. And I'm not sure (again, just my opinion) that a build system is the best place to do the configuration management. After all, configurations do change, and I prefer not to rebuild my systems every time I need to add a user account or update the MOTD. -s- From tom at ng23.net Wed Apr 9 15:32:57 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 09 Apr 2008 16:32:57 +0100 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <47FCDD8C.2050402@redhat.com> References: <47FCD7F4.7070603@ng23.net> <47FCDD8C.2050402@redhat.com> Message-ID: <47FCE1A9.6070108@ng23.net> > > Most likely not. It is expected to run as far back as RHEL3, though > not before. However, you /might/ be able to get it to work if you > rebuild the source rpm. I haven't tried it. i will try some more but i doubt it will work as it seems python-setuptools is not available for 7.3 From mdehaan at redhat.com Wed Apr 9 15:44:41 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 11:44:41 -0400 Subject: [et-mgmt-tools] Idea for Cobbler pxe rescue mode? (MEMTEST) In-Reply-To: References: <47FBDAAC.7040908@imageworks.com> <47FBDEAE.7090609@redhat.com> <47FBE1DD.3060008@redhat.com> <47FBF449.7090603@imageworks.com> Message-ID: <47FCE469.5030701@redhat.com> Pablo Iranzo G?mez wrote: > Hi > If anyone interested in previous memtest removals for patch is > attached (instead of the preceding patch) > > Regards > Pablo > > > > > Applied to devel branch. I tweaked it slightly... I'm copying memtest into /tftpboot/images instead of /tftpboot, as Cobbler auto-manages that directory and can keep it cleaned up. Works great! Thanks! --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 Apr 9 15:52:32 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 11:52:32 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <4A4CBDA3-326E-4347-8796-453E00164EEA@stanford.edu> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> <4A4CBDA3-326E-4347-8796-453E00164EEA@stanford.edu> Message-ID: <47FCE640.1020708@redhat.com> Sandor W. Sklar wrote: > > On Apr 9, 2008, at 12:05 AM, Aaron Lippold wrote: >> > <... snip ...> > >> Snipts and Groups >> >> An organization as sets of requirements - usually security or >> enterprise wide setting, files, etc. - that it uses to standardize >> the configuration management of its systems. These sets are usually >> organized by whatever organizational system they come up with but for >> the most part they are standard actions from the good old community >> best practices. ( set bootloader passwords, use sudo, install logging >> and setup, fixes known configuration issues with sendmail, copy over >> the standard MOTD, Company Banner etc. ) > > These things really sound like you would want a configuration > management tool (puppet, cfengine, etc.) to set those things after the > kickstart is complete. Depends. If you are installing a system for use in a disconnected environment the install needs to be correct by the time the install is done. You /can/ run the configuration management tool locally and remove the tool when you are done, however. That's still a possibility depending on requirements. From smooge at gmail.com Wed Apr 9 16:00:54 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 9 Apr 2008 10:00:54 -0600 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <47FCE1A9.6070108@ng23.net> References: <47FCD7F4.7070603@ng23.net> <47FCDD8C.2050402@redhat.com> <47FCE1A9.6070108@ng23.net> Message-ID: <80d7e4090804090900t529f6dd9u436577250f21dc6c@mail.gmail.com> On Wed, Apr 9, 2008 at 9:32 AM, Tom Brown wrote: > > > > > > Most likely not. It is expected to run as far back as RHEL3, though not > before. However, you /might/ be able to get it to work if you > > rebuild the source rpm. I haven't tried it. > > > > i will try some more but i doubt it will work as it seems python-setuptools > is not available for 7.3 > The python for 7.3 is pre-2 if I remember correctly. It is doubtful that you will be able to get the changes backported. I would say look to see if you can upgrade them to something other than 7.3 because well the security holes in those are pretty big. -- 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 mdehaan at redhat.com Wed Apr 9 16:08:05 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 12:08:05 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> Message-ID: <47FCE9E5.2070305@redhat.com> > > etc. > > Even better, if my sniptits take parameters, usually the "lock down > and configuration" difference are only 644 vs 640 perms or what my > password complexity requirments are for pam login or what the defualt > file upload size for apache should be, etc. These "actions" aren't > different - just what we put for the params of the action. Minor correction --- Snippets can already take parameters. The built in cobbler variables are already passed to them. In addition, others can also be passed along IIRC -- the cheetah syntax for this is "#set global foo" in the master template (see http://cheetahtemplate.org/) and then variables set there can be passed to templates. > > > Although it looks like from the other thread that this is going the > directory way, again, is this a mistake given that I don't really want > do some things until the end and some right at the beginning or I > really do want x to follow y to follow z. If we do it all by directory > I would have to name all my snipits 1_... 2_... which would really > make things not so elegant. I'm not sure that directory system was proposed. What /was/ proposed was a way to be able to indicate templates for systems in a way that they could be overriden. So, if you had a snippet named "driveconfig", it would first look for: /var/lib/cobbler/snippets/driveconfig/system/$system_name if it exists And would use that snippet if it existed, if not, failing back to: /var/lib/cobbler/snippets/driveconfig/profile/$profile_name if it exists And using it unless it didn't exist and failing back to: /var/lib/cobbler/snippets/driveconfig This would allow using the same "webserver" template for 500 servers, and still allowing for the 1 server that for some reason required a special exemption to get the configuration it needed, without having to create a new profile for "webserver-this-one-is-special". > > snipit_groups/group1 > > set_bootloader_password > set_password_retries > set_passwd_min_uppper > set_passwd_min_lower > set_motd > setup_aide > setup_logrotate > > This way I can call either a set of actions or a single one in the > cobbler kickstart template. > > ==== Kickstart Template ==== > > SNIPIT::_GROUP_ > SNIPIT::small_thing > SNIPIT::smaller_thing > > > Another thing I find useful in this type of setup is that I can also > make a mapping file : > > REG1:set_passwd_retries,set_passwd_min_upper,set_passwd_min_lower > REG2:setup_aide > REG3:set_motd > This is getting into config management territory. Have you looked at running a config management tool locally in post to execute some sort of policy? Or are there reasons for not doing this? I know there are ways to execute puppet without requiring a server, and it is probably easier to express those sort of requirements there as opposed to in Anaconda scripts with bash/sed/awk. --Michael From tom at ng23.net Wed Apr 9 16:12:48 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 09 Apr 2008 17:12:48 +0100 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <80d7e4090804090900t529f6dd9u436577250f21dc6c@mail.gmail.com> References: <47FCD7F4.7070603@ng23.net> <47FCDD8C.2050402@redhat.com> <47FCE1A9.6070108@ng23.net> <80d7e4090804090900t529f6dd9u436577250f21dc6c@mail.gmail.com> Message-ID: <47FCEB00.5040508@ng23.net> > > The python for 7.3 is pre-2 if I remember correctly. It is doubtful > that you will be able to get the changes backported. I would say look > to see if you can upgrade them to something other than 7.3 because > well the security holes in those are pretty big. > > indeed - hence koan for the rebuild - seems though that PXE or Koan CD are the only options thanks From mdehaan at redhat.com Wed Apr 9 16:17:12 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 12:17:12 -0400 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <47FCEB00.5040508@ng23.net> References: <47FCD7F4.7070603@ng23.net> <47FCDD8C.2050402@redhat.com> <47FCE1A9.6070108@ng23.net> <80d7e4090804090900t529f6dd9u436577250f21dc6c@mail.gmail.com> <47FCEB00.5040508@ng23.net> Message-ID: <47FCEC08.9090601@redhat.com> Tom Brown wrote: > >> >> The python for 7.3 is pre-2 if I remember correctly. It is doubtful >> that you will be able to get the changes backported. I would say look >> to see if you can upgrade them to something other than 7.3 because >> well the security holes in those are pretty big. >> >> > > indeed - hence koan for the rebuild - seems though that PXE or Koan CD > are the only options > > thanks > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools In all fairness -- they are much better options. --replace-self assumes the system is bootable (and probably network accessible if you want to automate mass replacement), so if you wreck your OS on any of them, you are going to want one of the other options anyway. If you don't have PXE capability in your network, fighting to get it is well worth it. If not, the ISO (other than requiring physical access -- assuming you don't have a management card that allows pushing ISO's down), will achieve PXE-equivalent capability. This works especially well if you use the pxe_just_once setting in /var/lib/cobbler/settings and set your machines up to PXE every time they boot. In this scenario, reinstallations can be done as simply as: cobbler system edit --name=FOO --netboot-enabled=1 --profile=newprofile (and cycle power once) Once the system completes installing, it will deactivate it's PXE configuration file and PXE through to local boot until you decide to reinstall it again. --Michael From tom at ng23.net Wed Apr 9 16:30:33 2008 From: tom at ng23.net (Tom Brown) Date: Wed, 09 Apr 2008 17:30:33 +0100 Subject: [et-mgmt-tools] koan - rh7.3 - possible? In-Reply-To: <47FCEC08.9090601@redhat.com> References: <47FCD7F4.7070603@ng23.net> <47FCDD8C.2050402@redhat.com> <47FCE1A9.6070108@ng23.net> <80d7e4090804090900t529f6dd9u436577250f21dc6c@mail.gmail.com> <47FCEB00.5040508@ng23.net> <47FCEC08.9090601@redhat.com> Message-ID: <47FCEF29.5060307@ng23.net> > > In all fairness -- they are much better options. --replace-self > assumes the system is bootable (and probably network accessible if you > want to automate mass replacement), so if you wreck your OS on any of > them, you are going to want one of the other options anyway. > > If you don't have PXE capability in your network, fighting to get it > is well worth it. If not, the ISO (other than requiring physical > access -- assuming you don't have a management card that allows > pushing ISO's down), will achieve PXE-equivalent capability. > > This works especially well if you use the pxe_just_once setting in > /var/lib/cobbler/settings and set your machines up to PXE every time > they boot. > > In this scenario, reinstallations can be done as simply as: > > cobbler system edit --name=FOO --netboot-enabled=1 --profile=newprofile > (and cycle power once) > > Once the system completes installing, it will deactivate it's PXE > configuration file and PXE through to local boot until you decide to > reinstall it again. > yes - i can PXE on _most_ of the network(s) just not this one, at the moment at least i am working on that, so until i reach that goal i'll use a koan CD - I have management cards where i can attach the iso so i dont actually have to be there thanks From Pablo.Iranzo at redhat.com Wed Apr 9 19:51:50 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Wed, 9 Apr 2008 21:51:50 +0200 (CEST) Subject: [et-mgmt-tools] PATCH KOAN: Add a reinstall entry in grub (Cobbler ticket #11) Message-ID: Hi all The attached patch for Koan will add a new command line "--add-reinstall-entry" that will use Koan to get a kernel, initrd, kickstart, etc to add a new entry called "Reinstall" on machines's grub not as default. Using that entry for booting, would be the same as running "koan -r --server=whatever; reboot" On each run, Koan will clean up those entries and set-up one, that will be the default for booting or not, depending on the "--add-reinstall-entry" presence or not (if present, not default boot) Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? -------------- next part -------------- A non-text attachment was scrubbed... Name: koan-reinstall.diff Type: text/x-diff Size: 2405 bytes Desc: URL: From mdehaan at redhat.com Wed Apr 9 19:57:27 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 09 Apr 2008 15:57:27 -0400 Subject: [et-mgmt-tools] PATCH KOAN: Add a reinstall entry in grub (Cobbler ticket #11) In-Reply-To: References: Message-ID: <47FD1FA7.20307@redhat.com> Pablo Iranzo G?mez wrote: > Hi all > The attached patch for Koan will add a new command line > "--add-reinstall-entry" that will use Koan to get a kernel, initrd, > kickstart, etc to add a new entry called "Reinstall" on machines's grub > not as default. > > Using that entry for booting, would be the same as running "koan > -r --server=whatever; reboot" > > On each run, Koan will clean up those entries and set-up one, that > will be the default for booting or not, depending on the > "--add-reinstall-entry" presence or not (if present, not default boot) > > Regards > Pablo > > > Nice. So as an example, suppose you wanted to, in kickstart, add an entry in grub that would allow you to reinstall the system, whenever you wanted, from the grub menu. All you would have to do is... %packages koan # or otherwise install the rpm with wget/rpm in %post if using RHEL 3/4 %post #set profilename =$getVar("profile",$name) koan --server=$server --replace-self --add-reinstall-entry --profile=$profilename I'll apply this and add it to the Wiki under the koan section shortly. Thanks! --Michael > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From ghoneycutt at hq.speakeasy.net Thu Apr 10 00:30:24 2008 From: ghoneycutt at hq.speakeasy.net (Garrett Honeycutt) Date: Wed, 09 Apr 2008 17:30:24 -0700 Subject: [et-mgmt-tools] Help using the Cobbler API in triggers In-Reply-To: <47FCDAD6.1040200@redhat.com> References: <47FC3A6B.5010308@hq.speakeasy.net> <47FC42C7.6080506@imageworks.com> <47FCDAD6.1040200@redhat.com> Message-ID: <47FD5FA0.2000701@hq.speakeasy.net> Michael DeHaan wrote: > Jennifer Cranfill wrote: >> Garrett Honeycutt wrote: >>> My goal is to access a variable within Cobbler, $hostname for example, >>> and use that in a trigger that is run whenever a system is added. Below >>> is some pseudo code to demonstrate my aim. >>> >>> os.system("/usr/local/sbin/dostuff.sh $hostname") >> >> Cobbler passes the name of the system as the first argument to the >> command. If your system name is the hostname, then in python you can >> just use something simple like: >> >> machine = sys.argv[1] >> >> If your system name is not the hostname then you can query the >> hostname of the system from Cobbler. Here is some python code I've >> been using: >> >> from cobbler import api >> cobbler_api = api.BootAPI() >> systems = cobbler_api.systems() >> box = systems.find(sys.argv[1]) >> >> I'm sure there are other (and probably better) ways as well. >> >> -- >> Jennifer Cranfill >> Systems Engineer >> Sony Pictures Imageworks >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > Right! I added that example here -- > https://fedorahosted.org/cobbler/wiki/CobblerTriggers -- so other people > could find it when they were > reading the docs. > > Thanks! > > > --Michael Thank you for all of your help. This is what I came up, not sure how optimal it is, as I do not code python. ========= getcert.trigger - add/system/post trigger =========== #!/usr/bin/python import os import sys from cobbler import api cobbler_api = api.BootAPI() # this is the systemname, not the hostname, so be sure to use the FQDN in the systemname machine = sys.argv[1] # location of getcert.sh script getcert_cmd = "/usr/local/sbin/getcert.sh" # set return code to 0 by default rc = 0 # build the command string cmd = getcert_cmd + " " + machine # log to cobbler's logs cobbler_api.log("running - " + cmd) # run the command and set the return code rc = os.system(cmd) # exit with return code sys.exit(rc) ==== end code ==== This allows me to run a script when I add a system that will pre-generate puppet certs. -g -- Garrett Honeycutt Sr. Systems Engineer www.speakeasy.net Voice * Data * Managed Services From drew.einhorn at gmail.com Thu Apr 10 01:18:37 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Wed, 9 Apr 2008 19:18:37 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server Message-ID: I am building a new cobbler server, going back to the beginning and starting form scratch. The links from the "Source RPM Build Instructions for RHEL5" section of the download page are broken. Not only that the first one: Grab python-setuputils from here links to a python-setuptools rpm, which is confusing, when trying to work around the problem by looking for the similar rpms in CentOS5 and 3rd Party repositories. I am trying I have: python-setuptools noarch 0.6c7-1.el5 epel python-cheetah .i386 2.0-0.1.rc8.el5.rf dag yum-utils. noarch 1.0.4-3.el5.centos.2 base So far it seems to be working The the breed ooption is new, since the last time I was paying attention. How well does it work with a Ubuntu Gutsy or Hardy distro? This go around I am going to try Xen based VMs. Need to read the documentation more carefully, So far I have not spotted the section that tells me how to setup the lvm storage for virt-file-size to allocate from. -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 14:52:00 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 10:52:00 -0400 Subject: [et-mgmt-tools] Help using the Cobbler API in triggers In-Reply-To: <47FD5FA0.2000701@hq.speakeasy.net> References: <47FC3A6B.5010308@hq.speakeasy.net> <47FC42C7.6080506@imageworks.com> <47FCDAD6.1040200@redhat.com> <47FD5FA0.2000701@hq.speakeasy.net> Message-ID: <47FE2990.1010302@redhat.com> Garrett Honeycutt wrote: > Michael DeHaan wrote: >> Jennifer Cranfill wrote: >>> Garrett Honeycutt wrote: >>>> My goal is to access a variable within Cobbler, $hostname for example, >>>> and use that in a trigger that is run whenever a system is added. >>>> Below >>>> is some pseudo code to demonstrate my aim. >>>> >>>> os.system("/usr/local/sbin/dostuff.sh $hostname") >>> >>> Cobbler passes the name of the system as the first argument to the >>> command. If your system name is the hostname, then in python you can >>> just use something simple like: >>> >>> machine = sys.argv[1] >>> >>> If your system name is not the hostname then you can query the >>> hostname of the system from Cobbler. Here is some python code I've >>> been using: >>> >>> from cobbler import api >>> cobbler_api = api.BootAPI() >>> systems = cobbler_api.systems() >>> box = systems.find(sys.argv[1]) >>> >>> I'm sure there are other (and probably better) ways as well. >>> >>> -- >>> Jennifer Cranfill >>> Systems Engineer >>> Sony Pictures Imageworks >>> >>> _______________________________________________ >>> et-mgmt-tools mailing list >>> et-mgmt-tools at redhat.com >>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> Right! I added that example here -- >> https://fedorahosted.org/cobbler/wiki/CobblerTriggers -- so other >> people could find it when they were >> reading the docs. >> >> Thanks! >> >> >> --Michael > > Thank you for all of your help. This is what I came up, not sure how > optimal it is, as I do not code python. You do now :) > > ========= getcert.trigger - add/system/post trigger =========== > #!/usr/bin/python > > import os > import sys > > from cobbler import api > cobbler_api = api.BootAPI() > > # this is the systemname, not the hostname, so be sure to use the FQDN > in the systemname > machine = sys.argv[1] > > # location of getcert.sh script > getcert_cmd = "/usr/local/sbin/getcert.sh" > > # set return code to 0 by default > rc = 0 > > # build the command string > cmd = getcert_cmd + " " + machine > > # log to cobbler's logs > cobbler_api.log("running - " + cmd) > > # run the command and set the return code > rc = os.system(cmd) > > # exit with return code > sys.exit(rc) > > ==== end code ==== > > This allows me to run a script when I add a system that will > pre-generate puppet certs. > > -g > From mdehaan at redhat.com Thu Apr 10 14:59:45 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 10:59:45 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: Message-ID: <47FE2B61.9050009@redhat.com> drew einhorn wrote: > I am building a new cobbler server, going back to the beginning > and starting form scratch. > > The links from the "Source RPM Build Instructions for RHEL5" > section of the download page are broken. > So they are. Thankfully these are in EPEL now so I can update the links/instructions. Will do. That's really all you have to do to install as well -- just configure your system to use EPEL as a yum repo and "yum install cobbler". There's not really a need to rebuild the source RPMs unless you are doing development on them. > > The the breed ooption is new, since the last time I was paying attention. > How well does it work with a Ubuntu Gutsy or Hardy distro? > Should do fine. Basically all --breed=debian does is change the kernel arguments so that what you feed to --kickstart is actually treated as a preseed. Ubuntu should work just the same. I believe if you leave it unmodified (no --breed parameter) the kernel arguments /might/ work with Ubuntu's mutated version of kickstart also, though you'll need to be careful about what goes in the template. > This go around I am going to try Xen based VMs. > Need to read the documentation more carefully, > > So far I have not spotted the section that tells me how > to setup the lvm storage for virt-file-size to allocate from. > "man lvm" (specifically pvcreate, vgcreate, but not lvcreate), followed by "man koan" for --virt-path where you name the volume group to carve out storage from. --Michael From mdehaan at redhat.com Thu Apr 10 15:03:14 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 11:03:14 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE2B61.9050009@redhat.com> References: <47FE2B61.9050009@redhat.com> Message-ID: <47FE2C32.1090600@redhat.com> Michael DeHaan wrote: > > That's really all you have to do to install as well -- just configure > your system to use EPEL as a yum repo Sorry, reading comprehension error from my part earlier. Yes, so you're trying to build the new versions before they are in EPEL. Gotcha. Get the missing RPMs from EPEL, and I'll update the instructions on that, then use rpmbuild as indicated and you should be good to go. Thanks! --Michael From drew.einhorn at gmail.com Thu Apr 10 19:13:03 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 13:13:03 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE2B61.9050009@redhat.com> References: <47FE2B61.9050009@redhat.com> Message-ID: On Thu, Apr 10, 2008 at 8:59 AM, Michael DeHaan wrote: > drew einhorn wrote: > > The the breed ooption is new, since the last time I was paying attention. > > How well does it work with a Ubuntu Gutsy or Hardy distro? > > > > > > Should do fine. Basically all --breed=debian does is change the kernel > arguments so that what you feed to --kickstart is actually treated as a > preseed. Ubuntu should work just the same. I believe if you leave it > unmodified (no --breed parameter) the kernel arguments /might/ work with > Ubuntu's mutated version of kickstart also, though you'll need to be > careful about what goes in the template. > > Felt like the "cobbler import" should take the breed option, but it was rejected so I tried, an import without it: sudo cobbler import --mirror=/mnt/iso1 --name=ubuntu-7.10-desktop-i386 Things started flying by on the screen. So far so good then: sent 728274605 bytes received 13682 bytes 5757219.66 bytes/sec total size is 728143597 speedup is 1.00 ---------------- (adding distros) - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu ... longer and longer symlinks follow. Uh. Oh. We are chasing our tail!!!! Untill we crash - creating new distro: ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 54, in main return BootCLI().run(sys.argv) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 43, in run return self.loader.run(args) File "/usr/lib/python2.4/site-packages/cobbler/commands.py", line 69, in run return fn.run() File "/usr/lib/python2.4/site-packages/cobbler/modules/cli_misc.py", line 95, in run rsync_flags=self.options.rsync_flags File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 351, in import_tree return importer.run() File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 126, in run os.path.walk(self.path, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 335, in distro_adder os.path.walk(fullname, self.distro_adder, {}) File "/usr/lib/python2.4/posixpath.py", line 298, in walk walk(name, func, arg) File "/usr/lib/python2.4/posixpath.py", line 290, in walk func(arg, top, names) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 342, in distro_adder self.add_entry(dirname,kernel,initrd) File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 488, in add_entry self.distros.add(distro,save=True) File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line 200, in add self.lite_sync.add_single_distro(ref.name) File "/usr/lib/python2.4/site-packages/cobbler/action_litesync.py", line 60, in add_single_distro self.sync.write_distro_file(distro) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 940, in write_distro_file fd = open(filename, "w+") IOError: [Errno 36] File name too long: '/var/www/cobbler/distros/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386' [drew at funGus ~]$ -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 19:20:41 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 15:20:41 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> Message-ID: <47FE6889.8090001@redhat.com> drew einhorn wrote: > On Thu, Apr 10, 2008 at 8:59 AM, Michael DeHaan wrote: > >> drew einhorn wrote: >> > > >>> The the breed ooption is new, since the last time I was paying attention. >>> How well does it work with a Ubuntu Gutsy or Hardy distro? >>> >>> >>> >> Should do fine. Basically all --breed=debian does is change the kernel >> arguments so that what you feed to --kickstart is actually treated as a >> preseed. Ubuntu should work just the same. I believe if you leave it >> unmodified (no --breed parameter) the kernel arguments /might/ work with >> Ubuntu's mutated version of kickstart also, though you'll need to be >> careful about what goes in the template. >> >> >> > > Felt like the "cobbler import" should take the breed option, but it was rejected > so I tried, an import without it: > > sudo cobbler import --mirror=/mnt/iso1 --name=ubuntu-7.10-desktop-i386 > Expected. ATM cobbler import does not support non Red Hat based distros. Support is not in plan -- at least not by me, anyway. "cobbler distro add", however, does work thanks to patches already submitted to add that support. Should you be wanting to add other distro import capability, I welcome patches -- something like action_foreign_import.py is probably a good fit rather than trying to make the existing Red Hat-based import code work elsewhere -- namely because it's already pretty complicated to detect varying tree layouts and mirror sources and so forth. --Michael From drew.einhorn at gmail.com Thu Apr 10 19:24:30 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 13:24:30 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> Message-ID: But maybe it's because I have not yet installed the newer rpms from EPEL. On Thu, Apr 10, 2008 at 1:13 PM, drew einhorn wrote: > On Thu, Apr 10, 2008 at 8:59 AM, Michael DeHaan wrote: > > drew einhorn wrote: > > > > The the breed ooption is new, since the last time I was paying attention. > > > How well does it work with a Ubuntu Gutsy or Hardy distro? > > > > > > > > > > Should do fine. Basically all --breed=debian does is change the kernel > > arguments so that what you feed to --kickstart is actually treated as a > > preseed. Ubuntu should work just the same. I believe if you leave it > > unmodified (no --breed parameter) the kernel arguments /might/ work with > > Ubuntu's mutated version of kickstart also, though you'll need to be > > careful about what goes in the template. > > > > > > Felt like the "cobbler import" should take the breed option, but it was rejected > so I tried, an import without it: > > sudo cobbler import --mirror=/mnt/iso1 --name=ubuntu-7.10-desktop-i386 > > Things started flying by on the screen. So far so good then: > > sent 728274605 bytes received 13682 bytes 5757219.66 bytes/sec > total size is 728143597 speedup is 1.00 > ---------------- (adding distros) > - following symlink: /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu > - following symlink: > /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu > > ... longer and longer symlinks follow. > > Uh. Oh. We are chasing our tail!!!! > > Untill we crash > > - creating new distro: > ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 > Traceback (most recent call last): > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 54, in main > return BootCLI().run(sys.argv) > File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 43, in run > return self.loader.run(args) > File "/usr/lib/python2.4/site-packages/cobbler/commands.py", line 69, in run > return fn.run() > File "/usr/lib/python2.4/site-packages/cobbler/modules/cli_misc.py", > line 95, in run > rsync_flags=self.options.rsync_flags > File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 351, in > import_tree > return importer.run() > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 126, in run > os.path.walk(self.path, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 335, in distro_adder > os.path.walk(fullname, self.distro_adder, {}) > File "/usr/lib/python2.4/posixpath.py", line 298, in walk > walk(name, func, arg) > File "/usr/lib/python2.4/posixpath.py", line 290, in walk > func(arg, top, names) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 342, in distro_adder > self.add_entry(dirname,kernel,initrd) > File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", > line 488, in add_entry > self.distros.add(distro,save=True) > File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line > 200, in add > self.lite_sync.add_single_distro(ref.name) > File "/usr/lib/python2.4/site-packages/cobbler/action_litesync.py", > line 60, in add_single_distro > self.sync.write_distro_file(distro) > File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line > 940, in write_distro_file > fd = open(filename, "w+") > IOError: [Errno 36] File name too long: > '/var/www/cobbler/distros/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386' > [drew at funGus ~]$ > > > > > -- > Drew Einhorn > -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 19:23:45 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 15:23:45 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> Message-ID: <47FE6941.8070605@redhat.com> drew einhorn wrote: > But maybe it's because I have not yet installed the newer rpms from EPEL. > > See previous email. Ubuntu is not supported presently for "import" commands. See "cobbler distro add" and do things manually, and you should be ok. From drew.einhorn at gmail.com Thu Apr 10 19:56:59 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 13:56:59 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE2B61.9050009@redhat.com> References: <47FE2B61.9050009@redhat.com> Message-ID: On Thu, Apr 10, 2008 at 8:59 AM, Michael DeHaan wrote: > drew einhorn wrote: > > > I am building a new cobbler server, going back to the beginning > > and starting form scratch. > > > > The links from the "Source RPM Build Instructions for RHEL5" > > section of the download page are broken. > > > > > > So they are. Thankfully these are in EPEL now so I can update the > links/instructions. Will do. > > That's really all you have to do to install as well -- just configure your > system to use EPEL as a yum repo > and "yum install cobbler". There's not really a need to rebuild the > source RPMs unless you are doing development on them. > yum-utils is not found in CentOS5 EPEL, unless I am looking in the wrong place. We do have: yum-utils. noarch 1.0.4-3.el5.centos.2 base in the CentOS 5.1 base distro. And there is no python-setuputils in EPEL, there is: python-setuptools 0.6c7 1.el5 src 261 KiB Fri Sep 14 16:21:06 2007 Both of the above are working for me, so far. The cheetah from EPEL python-cheetah 2.0.1 1.el5 src 214 KiB Tue Jan 22 15:13:20 2008 does appear to be newer than the one I earlier snagged from the dag repo python-cheetah .i386 2.0-0.1.rc8.el5.rf dag This is the first time I have used anything from the EPEL repo. I have been leery of the EPEL repo, since there was a time, not long ago, when their packagers were blatantly refusing to cooperate with other repos on compatibility issues. I hope times have changed. -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 19:58:23 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 15:58:23 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> Message-ID: <47FE715F.1050905@redhat.com> drew einhorn wrote: > On Thu, Apr 10, 2008 at 8:59 AM, Michael DeHaan wrote: > >> drew einhorn wrote: >> >> >>> I am building a new cobbler server, going back to the beginning >>> and starting form scratch. >>> >>> The links from the "Source RPM Build Instructions for RHEL5" >>> section of the download page are broken. >>> >>> >>> >> So they are. Thankfully these are in EPEL now so I can update the >> links/instructions. Will do. >> >> That's really all you have to do to install as well -- just configure your >> system to use EPEL as a yum repo >> and "yum install cobbler". There's not really a need to rebuild the >> source RPMs unless you are doing development on them. >> >> > > yum-utils is not found in CentOS5 EPEL, unless I am looking in the wrong place. > > We do have: > > yum-utils. noarch 1.0.4-3.el5.centos.2 base > > in the CentOS 5.1 base distro. > There is no CentOS 5 EPEL, there is only EPEL, which works for all derivative distributions equally. The instructions on the website do say "RHEL 5 rebuild" instructions :) > I have been leery of the EPEL repo, since there was a time, not long ago, > when their packagers were blatantly refusing to cooperate with other > repos on compatibility issues. I hope times have changed. > > I don't see a basis for that at all. EPEL's goal is providing a common repo for packages usable by all yum consumers. It's a fantastic service as it allows any Fedora hosted project to also offer up RPMs to Enterprise Linux using the same repositories. yum-utils is in the testing repos, so perhaps you were looking in stable -- either way, it's not needed if you are running CentOS as that was in the base repo. --Michael From drew.einhorn at gmail.com Thu Apr 10 20:23:27 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 14:23:27 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE715F.1050905@redhat.com> References: <47FE2B61.9050009@redhat.com> <47FE715F.1050905@redhat.com> Message-ID: > There is no CentOS 5 EPEL, there is only EPEL, which works for all > derivative distributions equally. > The instructions on the website do say "RHEL 5 rebuild" instructions :) > > Probably it's because I was looking in EPEL stable, instead of testing. The link from the cobbler page takes you to here: http://fedoraproject.org/wiki/EPEL which has separate links for: RHEL4 (CentOS4), and RHEL5 (CentOS5) If we are supposed to get them from a different testing release, it's not clear how to get there from the link you provide. -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 20:29:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 16:29:33 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> <47FE715F.1050905@redhat.com> Message-ID: <47FE78AD.5070509@redhat.com> drew einhorn wrote: >> There is no CentOS 5 EPEL, there is only EPEL, which works for all >> derivative distributions equally. >> The instructions on the website do say "RHEL 5 rebuild" instructions :) >> >> >> > > Probably it's because I was looking in EPEL stable, instead of testing. > > The link from the cobbler page takes you to here: > > http://fedoraproject.org/wiki/EPEL > > which has separate links for: > > RHEL4 (CentOS4), and > RHEL5 (CentOS5) > > If we are supposed to get them from a different testing release, it's not clear > how to get there from the link you provide. > > Yes... I'll update the bottom part to link to the testing ones for those instructions. Thanks! From drew.einhorn at gmail.com Thu Apr 10 20:39:37 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 14:39:37 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE78AD.5070509@redhat.com> References: <47FE2B61.9050009@redhat.com> <47FE715F.1050905@redhat.com> <47FE78AD.5070509@redhat.com> Message-ID: On Thu, Apr 10, 2008 at 2:29 PM, Michael DeHaan wrote: > Yes... I'll update the bottom part to link to the testing ones for those > instructions. > > Thanks! > Thank you!! You continue to amaze me with the speed with which respond to and resolve issues that we raise. -- Drew Einhorn From drew.einhorn at gmail.com Thu Apr 10 21:40:53 2008 From: drew.einhorn at gmail.com (drew einhorn) Date: Thu, 10 Apr 2008 15:40:53 -0600 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: <47FE6889.8090001@redhat.com> References: <47FE2B61.9050009@redhat.com> <47FE6889.8090001@redhat.com> Message-ID: > > > > sudo cobbler import --mirror=/mnt/iso1 --name=ubuntu-7.10-desktop-i386 > > > > > > Expected. ATM cobbler import does not support non Red Hat based distros. > Support is not in plan -- at least not by me, anyway. "cobbler distro add", > however, does work thanks to patches already submitted to add that support. > > Should you be wanting to add other distro import capability, I welcome > patches -- something like action_foreign_import.py is probably a good fit > rather than trying to make the existing Red Hat-based import code work > elsewhere -- namely because it's already pretty complicated to detect > varying tree layouts and mirror sources and so forth. > > I've got to clean out the junk that's cluttering up the database, etc. with the results of the unsuccessful import attempt. ]$ sudo cobbler report distro : CentOS-5.1-i386 kernel : /var/www/cobbler/ks_mirror/CentOS-5.1/images/pxeboot/vmlinuz initrd : /var/www/cobbler/ks_mirror/CentOS-5.1/images/pxeboot/initrd.img kernel options : {} architecture : x86 ks metadata : {'tree': 'http://@@http_server@@/cblr/links/CentOS-5.1-i386'} breed : redhat distro : CentOS-5.1-xen-i386 kernel : /var/www/cobbler/ks_mirror/CentOS-5.1/images/xen/vmlinuz initrd : /var/www/cobbler/ks_mirror/CentOS-5.1/images/xen/initrd.img kernel options : {} architecture : x86 ks metadata : {'tree': 'http://@@http_server@@/cblr/links/CentOS-5.1-xen-i386'} breed : redhat distro : ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 kernel : /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/casper/vmlinuz initrd : /var/www/cobbler/ks_mirror/ubuntu-7.10-desktop-i386/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/casper/initrd.gz kernel options : {} architecture : x86 ks metadata : {} breed : redhat profile : CentOS-5.1-i386 distro : CentOS-5.1-i386 kickstart : /etc/cobbler/sample.ks kernel options : {} ks metadata : {} virt file size : 5 virt ram : 512 virt type : auto virt path : virt bridge : xenbr0 virt cpus : 1 repos : [] dhcp tag : default server : <> profile : CentOS-5.1-xen-i386 distro : CentOS-5.1-xen-i386 kickstart : /etc/cobbler/sample.ks kernel options : {} ks metadata : {} virt file size : 5 virt ram : 512 virt type : auto virt path : virt bridge : xenbr0 virt cpus : 1 repos : [] dhcp tag : default server : <> ]$ sudo cobbler distro remove --name=ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 1003, in rmfile os.unlink(path) OSError: [Errno 36] File name too long: '/var/www/cobbler/profiles/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386' Error deleting /var/www/cobbler/profiles/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 I can probably figure out how to clean out /var/lib/cobbler using a text editor, and I'm pretty sure I can find a few more places that need to be cleaned out. But I'm not sure I can find them all. > > --Michael > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- Drew Einhorn From mdehaan at redhat.com Thu Apr 10 21:49:47 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Thu, 10 Apr 2008 17:49:47 -0400 Subject: [et-mgmt-tools] Starting again with a new cobbler server In-Reply-To: References: <47FE2B61.9050009@redhat.com> <47FE6889.8090001@redhat.com> Message-ID: <47FE8B7B.2030204@redhat.com> drew einhorn wrote: > > OSError: [Errno 36] File name too long: > '/var/www/cobbler/profiles/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386' > Error deleting /var/www/cobbler/profiles/ubuntu-7.10-desktop-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-ubuntu-casper-i386 > > I can probably figure out how to clean out /var/lib/cobbler using a > text editor, and I'm pretty sure I can find a few more places that > need to be cleaned out. But I'm not sure I can find them all. > > > vi /var/lib/cobbler/distros and /var/lib/cobbler/profiles, then cd into /var/www/cobbler/ks_mirror and possibly remove the ubuntu-googolplex and that'll be it. When editing the distros file, be sure to edit just the records for those distros/profiles in question. Also a good reason to keep a backup of /var/lib/cobbler around just in case you ever need it... I'm considering writing some sort of simple backup/restore facility into a future version of cobbler since it's really just a few directories/files we care about. --Michael From fj7025cf at aa.jp.fujitsu.com Fri Apr 11 00:22:33 2008 From: fj7025cf at aa.jp.fujitsu.com (Hiroyuki Kaguchi) Date: Fri, 11 Apr 2008 09:22:33 +0900 Subject: [et-mgmt-tools] [PATCH] comparing MAC address is changed to case insensitive Message-ID: <47FEAF49.1090300@aa.jp.fujitsu.com> MAC address is case sensitive in "countMACaddr" method. This patch changes from case sensitive to case insensitive. Signed-off-by: Hiroyuki Kaguchi diff -r 6462dfd3e606 virtinst/Guest.py --- a/virtinst/Guest.py Tue Apr 08 15:35:49 2008 -0400 +++ b/virtinst/Guest.py Fri Apr 11 02:02:50 2008 +0900 @@ -369,10 +369,8 @@ ctx = doc.xpathNewContext() try: try: - count += ctx.xpathEval("count(/domain/devices/interface/mac[@address='%s'])" + count += ctx.xpathEval("count(/domain/devices/interface/mac[translate(@address, 'abcdef', 'ABCDEF')='%s'])" % self.macaddr.upper()) - count += ctx.xpathEval("count(/domain/devices/interface/mac[@address='%s'])" - % self.macaddr.lower()) except: continue finally: From rjones at redhat.com Fri Apr 11 11:39:49 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Apr 2008 12:39:49 +0100 Subject: [et-mgmt-tools] Packaging virt-manager for forsightlinux In-Reply-To: <4ab4fac8bd46d0842ebb685cfc3eb922@haigmail.com> References: <20080408103353.GA4783@amd.home.annexia.org> <4ab4fac8bd46d0842ebb685cfc3eb922@haigmail.com> Message-ID: <20080411113949.GA20572@amd.home.annexia.org> On Tue, Apr 08, 2008 at 09:03:24AM -0400, lhaig-haigmail.com wrote: > I sent that a while ago and then found out that virsh does not exist. OK. virsh is part of libvirt. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Fri Apr 11 11:42:52 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 11 Apr 2008 12:42:52 +0100 Subject: [et-mgmt-tools] [PATCH] comparing MAC address is changed to case insensitive In-Reply-To: <47FEAF49.1090300@aa.jp.fujitsu.com> References: <47FEAF49.1090300@aa.jp.fujitsu.com> Message-ID: <20080411114252.GB20572@amd.home.annexia.org> On Fri, Apr 11, 2008 at 09:22:33AM +0900, Hiroyuki Kaguchi wrote: > MAC address is case sensitive in "countMACaddr" method. > This patch changes from case sensitive to case insensitive. You also have to note that 1:2:3:4:5:6 is the same as 01:02:03:04:05:06. Comparing MAC addresses is hard :-) There's some C code in libvirt (src/utils.c IIRC) which Jim Meyering wrote that does a correct compare on MAC addresses. Should be easier in Python 'coz you can split the string and compare each component numerically. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From lhaig at haigmail.com Fri Apr 11 18:19:37 2008 From: lhaig at haigmail.com (lhaig-haigmail.com) Date: Fri, 11 Apr 2008 14:19:37 -0400 Subject: [et-mgmt-tools] Packaging virt-manager for forsightlinux In-Reply-To: <20080411113949.GA20572@amd.home.annexia.org> References: <20080411113949.GA20572@amd.home.annexia.org> Message-ID: Hi Richard, Thanks for your help. I will go and make sure I get all the relevant packages built and installed before I make my name arse again :-) Thanks again Lance On Fri, 11 Apr 2008 12:39:49 +0100, "Richard W.M. Jones" wrote: > On Tue, Apr 08, 2008 at 09:03:24AM -0400, lhaig-haigmail.com wrote: >> I sent that a while ago and then found out that virsh does not exist. > > OK. virsh is part of libvirt. > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > virt-p2v converts physical machines to virtual machines. Boot with a > live CD or over the network (PXE) and turn machines into Xen guests. > http://et.redhat.com/~rjones/virt-p2v > > _______________________________________________ > 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 Fri Apr 11 20:05:18 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 11 Apr 2008 16:05:18 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> Message-ID: <47FFC47E.6010400@redhat.com> >> >> What if we changed the semantics of... >> >> SNIPPET::foosball >> >> which would now be smart and would pull one of the following, >> whichever exists first: >> >> /var/lib/cobbler/snippets/system/foosball/$system_name >> /var/lib/cobbler/snippets/profile/foosball/$profile_name >> /var/lib/cobbler/snippets/distro/foosball/$distro_name >> /var/lib/cobbler/snippets/foosball >> >> whichever was found first. >> >> I think this is what you're getting at and could be done fairly >> cleanly without being package specific. >> >> Of course the stock install would lay down none of these paths except >> the directories and this would largely be just documented >> if you decide to use it (on the Wiki). > > I think that would be perfect! Thanks! > > -s- I've implemented this here -- with only a slight change to the way the above behavior works (basically there are no distro-overrides and the paths are slightly different): https://fedorahosted.org/cobbler/wiki/KickstartSnippets It's under the "Advanced Snippets" section and is available now in the git/devel branch. Testing welcome! --Michael From ssklar at stanford.edu Fri Apr 11 20:13:30 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Fri, 11 Apr 2008 13:13:30 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <47FFC47E.6010400@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: On Apr 11, 2008, at 1:05 PM, Michael DeHaan wrote: > > I've implemented this here -- with only a slight change to the way > the above behavior works (basically there are no distro-overrides > and the paths are slightly different): > > https://fedorahosted.org/cobbler/wiki/KickstartSnippets > > It's under the "Advanced Snippets" section and is available now in > the git/devel branch. Testing welcome! > > --Michael You are awesome! I will try this out ASAP (this weekend, I hope) and let you know how it works out. Thanks! Thanks! Thanks! -s- From lippold at gmail.com Sat Apr 12 16:56:25 2008 From: lippold at gmail.com (Aaron Lippold) Date: Sat, 12 Apr 2008 12:56:25 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <47FCE9E5.2070305@redhat.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> <47FCE9E5.2070305@redhat.com> Message-ID: <39d2723b0804120956o1e96d7e0s7a6bfd86d7e450dc@mail.gmail.com> On Wed, Apr 9, 2008 at 12:08 PM, Michael DeHaan wrote: > > > > etc. > > > > Even better, if my sniptits take parameters, usually the "lock down and > > configuration" difference are only 644 vs 640 perms or what my password > > complexity requirments are for pam login or what the defualt file upload > > size for apache should be, etc. These "actions" aren't different - just what > > we put for the params of the action. > > > > Minor correction --- Snippets can already take parameters. The built in > cobbler variables are already passed to them. In addition, others can also > be passed along IIRC -- the cheetah syntax for this is "#set global foo" in > the master template (see http://cheetahtemplate.org/) and then variables > set there can be passed to templates. > > > > > > Although it looks like from the other thread that this is going the > > directory way, again, is this a mistake given that I don't really want do > > some things until the end and some right at the beginning or I really do > > want x to follow y to follow z. If we do it all by directory I would have to > > name all my snipits 1_... 2_... which would really make things not so > > elegant. > > > > I'm not sure that directory system was proposed. What /was/ proposed was > a way to be able to indicate templates for systems in a way that they could > be overriden. > > So, if you had a snippet named "driveconfig", it would first look for: > /var/lib/cobbler/snippets/driveconfig/system/$system_name if it exists > > And would use that snippet if it existed, if not, failing back to: > /var/lib/cobbler/snippets/driveconfig/profile/$profile_name if it exists > > And using it unless it didn't exist and failing back to: > /var/lib/cobbler/snippets/driveconfig > > This would allow using the same "webserver" template for 500 servers, and > still allowing for the 1 server that for some reason required a special > exemption to get the configuration it needed, without having to create a new > profile for "webserver-this-one-is-special". > > > > snipit_groups/group1 > > > > set_bootloader_password > > set_password_retries > > set_passwd_min_uppper > > set_passwd_min_lower > > set_motd > > setup_aide > > setup_logrotate > > > > This way I can call either a set of actions or a single one in the > > cobbler kickstart template. > > > > ==== Kickstart Template ==== > > > > SNIPIT::_GROUP_ > > SNIPIT::small_thing > > SNIPIT::smaller_thing > > > > > > Another thing I find useful in this type of setup is that I can also > > make a mapping file : > > > > REG1:set_passwd_retries,set_passwd_min_upper,set_passwd_min_lower > > REG2:setup_aide > > REG3:set_motd > > > > > This is getting into config management territory. Have you looked at > running a config management tool locally in post to execute some sort of > policy? Or are there reasons for not doing this? I know there are ways to > execute puppet without requiring a server, and it is probably easier to > express those sort of requirements there as opposed to in Anaconda scripts > with bash/sed/awk. I did look at using puppet and talked to someone about CFEngine. Both say they can run with our without a server. Your right though I would need to basically assume that this will be in a disconnected environment but I would like to look at trying to make that not the case. So what I was hoping to get at was that I could break all these little actions into smaller pieces then call a group of them as a set. That's were my idea of snippets and triggers came from. Here are some examples of my post actions. # GEN000420 (G011) # This part creates the same login banner once your username and password has been entered. This has linefeeds in it. # Text needs to be cleaned up a touch. echo "Locking down GEN000420" perl -npe 's/exit\s0/\n/' -i /etc/X11/gdm/Init/Default cat << 'EOF' >> /etc/X11/gdm/Init/Default /usr/bin/gdialog --yesno "`cat /etc/issue` Agree = 'OK' Disagree = 'Cancel'" if ( test 1 -eq $? ); then /usr/sbin/gdm-safe-restart fi exit 0 EOF echo "GEN000420 Completed" # GEN000920 (G023) echo "Locking down GEN000920" # Correct the permissions on /root to a DISA allowed 700 chmod 700 /root echo "GEN000920 Complete" # GEN000980 (G026) echo "GEN000980 Start" # Direct root logins are only allowed via tty1 echo "tty1" > /etc/securetty echo "GEN000980 Completed" # GEN000960 (G025) echo "Locking down GEN000960" # If we're not running an POP/IMAP server, remove the user dovecot rpm -q dovecot 2>&1 > /dev/null if [ a$? = "a1" ] then userdel dovecot else echo "dovecot package installed, not deleting user dovecot" fi # If we're not running named, delete the user rpm -q bind 2>&1 > /dev/null if [ a$? = "a1" ] then userdel named else echo "bind package installed, not deleting user named" fi echo "GEN000960 Complete" # GEN001480 (G053) # Correct the Red Hat supplied modes on these directories echo "Locking down GEN001480" chmod 750 /var/crash /var/www/usage /usr/libexec/dovecot echo "GEN001480 Complete" # GEN001569 # Change all user files to mode 740 echo "Locking down GEN001569" find /home -name '.*' -type f -exec chmod -R 740 {} \; find /root -name '.*' -type f -exec chmod -R 740 {} \; echo "GEN001569 Complete" # GEN002260 (G076) echo "Locking down GEN0002260" # check local device files against baseline # as a note, it may be sufficient to do a rpm --verify on the associated # block device packabes (devfs?) find /dev -type b -or -type c -or -type s >> /root/blockdevices echo "GEN002260 Complete" # GEN002560 # Reset the umasks for all users to 077 echo "Locking down GEN002560" perl -npe 's/umask\s+0\d2/umask 077/g' -i /etc/bashrc perl -npe 's/umask\s+0\d2/umask 077/g' -i /etc/csh.cshrc echo "GEN002560 Complete" # GEN002720 ~ GEN002840 # This will require refinement. Commented rules do not insert w/o an error echo "Locking down audit system (GEN002720 ~ GEN002840)" cat << 'EOF' > /etc/audit/audit.rules ## Submitted by JasonM at FSO. # This file contains the auditctl rules that are loaded # whenever the audit daemon is started via the initscripts. # The rules are simply the parameters that would be passed # to auditctl. # First rule - delete all -D # Feel free to add below this line. See auditctl man page # Increase the buffers to survive stress events -b 256 -e 1 # Audit Failed opens -a exit,always -S open -F success!=0 # # Audit success and failure of delete -a exit,always -S unlink -S rmdir # # Audit success and failure of admin actions #-a task,always -F uid=0 -w /var/log/audit/ -k ADMIN -w /etc/auditd.conf -k ADMIN -w /etc/audit.rules -k ADMIN -a exit,always -S stime -S acct -S reboot -S swapon -S settimeofday -S setrlimit -a exit,always -S setdomainname -S sched_setparam -S sched_setscheduler EOF echo "GEN002720 ~ GEN002840 Complete (Please review for your own audit needs)" # GEN002860 (G674) # Rotate the audit-logs on a daily basis; keep them all echo "Locking down GEN002860" cat << 'EOF' > /etc/logrotate.d/audit /var/log/audit/audit.log { daily notifempty missingok postrotate /sbin/service auditd restart 2> /dev/null > /dev/null || true endscript } EOF echo "GEN002860 Complete" # GEN002660 (G093) # SRR does not check to see that auditing is actually running. echo "Locking down GEN002600" chkconfig auditd on echo "GEN002660 Complete" # GEN002680 (G094) # reset permissions on audit logs echo "Locking down GEN002680" chmod 700 /var/log/audit chmod -R 600 /var/log/audit/* echo "GEN002680 Complete" # GEN003600 echo "Locking down GEN003600" echo "net.ipv4.tcp_max_syn_backlog = 1280" >> /etc/sysctl.conf echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf echo "GEN003600 Complete" # LNX00520 (L208) echo "Locking down LNX00520" chmod 600 /etc/sysctl.conf echo "LNX00520 Complete" # LNX00580 (L222) echo "Locking down LNX00580" perl -npe 's/ca::ctrlaltdel:\/sbin\/shutdown/#ca::ctrlaltdel:\/sbin\/shutdown/' -i /etc/inittab echo "LNX00580 Complete" # G618 (removed) echo "G618 removed..." find /dev -name "*ty*" -exec chmod 700 {} \; # GEN004640 (V126) echo "Locking down GEN004640" perl -npe 's/^decode/#decode/' -i /etc/aliases newaliases echo "GEN004640 Complete" My thinking was to break them up into snippets then for the once I could, define variables to make them more useful. What I liked about this was that I could then use the snippets in other places. But perhaps puppet is a good choice or something like it. Although one of the selling points I do want to try to keep is that we are using base technology. I am hoping to keep my provisioning and upkeep system as simple as possible. --Michael > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssklar at stanford.edu Sun Apr 13 03:40:28 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Sat, 12 Apr 2008 20:40:28 -0700 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: <47FFC47E.6010400@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: On Apr 11, 2008, at 1:05 PM, Michael DeHaan wrote: > > I've implemented this here -- with only a slight change to the way > the above behavior works (basically there are no distro-overrides > and the paths are slightly different): > > https://fedorahosted.org/cobbler/wiki/KickstartSnippets > > It's under the "Advanced Snippets" section and is available now in > the git/devel branch. Testing welcome! I've tested this out with a fairly simple contrived example, and it worked perfectly. I created the following files and directories: # find /var/lib/cobbler/snippets -type f /var/lib/cobbler/snippets/packages /var/lib/cobbler/snippets/post /var/lib/cobbler/snippets/pre /var/lib/cobbler/snippets/per_profile/packages/testprofile /var/lib/cobbler/snippets/per_profile/post/testprofile /var/lib/cobbler/snippets/per_profile/pre/testprofile I created this profile: # cobbler profile report --name=testprofile profile : testprofile parent : rhel5Server-x86_64 kickstart : /etc/cobbler/foo.ks (... snip ...) And then added two system records: # cobbler system add --name=system1 --ip=172.24.10.10 --mac="00:16:3e: 43:22:02" --profile=rhel5Server-x86_64 # cobbler system add --name=system2 --ip=172.24.20.20 --mac="00:16:3e: 40:0a:a3" --profile=testprofile ... and ran "cobbler sync"; the rendered kickstarts in /var/www/ cobbler/kickstarts_sys/{system1,system2}/ks.cfg contained exactly what I expected (system1's had the contents of snippets/ {packages,post,pre}, and system2's had the contents of snippets/ per_profile/{packages,post,pre}/testprofile.) This is a totally awesome improvement, and when the devel version is ready for prime-time, it is going to make a *huge* difference in the simplicity of our systems deployment. I've got a few comments about the testing process and some issues I ran into; these comments shouldn't be construed as criticism, as I expect most of those issues are of my own making or ignorance. That said: * I'd never used "git", nor installed it before. It took me a little bit to figure out how to get it onto an RHEL5 system, but once I set up the EPEL yum repo, it installed cleanly. The PatchProcess wiki page helped immensely in getting going, but I think it would be useful to have a "How to build a devel branch RPM on an RHEL5 system for dummies" page (I'd be happy to write it, unless y'all think this is something that shouldn't be in the wiki.) * The last version of cobbler I built (from the src.rpm) was 0.8.2. Sometime between that version and the devel, a dependancy on the python-ldap module was added. The RPM built, but all cobbler actions failed with the traceback: ... (snip) File "/usr/lib/python2.4/site-packages/cobbler/modules/ authn_ldap.py", line 20, in ? import ldap ImportError: No module named ldap Perhaps I just missed something that stated that requirement. It would be really nice, though, if those of us that have no use for the authentication parts (ldap, for one) could disable it, perhaps with a config variable like "use_ldap: 0". * This might be a known issue, but when I imported a distro ... # mount -o loop ./rhel-5.1-server-x86_64-dvd.iso /mnt # cobbler import --path=/mnt --name=rhel5Server-x86_64 ... it ran fine, and then exited with the below traceback. The distro appeared to suffer no ill effect from this error, or, at least it worked for everything that I tested in this limited setup environment: - processing: /var/www/cobbler/ks_mirror/rhel5Server-x86_64/images/xen ---------------- (associating kickstarts) - finding default kickstart template for redhat 5.0 - tree: http://@@http_server@@/cblr/links/rhel5Server-x86_64 Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 53, in main return BootCLI().run(sys.argv) File "/usr/lib/python2.4/site-packages/cobbler/cobbler.py", line 42, in run return self.loader.run(args) File "/usr/lib/python2.4/site-packages/cobbler/commands.py", line 69, in run return fn.run() File "/usr/lib/python2.4/site-packages/cobbler/modules/ cli_misc.py", line 97, in run arch=self.options.arch File "/usr/lib/python2.4/site-packages/cobbler/api.py", line 351, in import_tree return importer.run() File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 155, in run self.kickstart_finder() File "/usr/lib/python2.4/site-packages/cobbler/action_import.py", line 224, in kickstart_finder self.distros.add(distro,save=True) # re-save File "/usr/lib/python2.4/site-packages/cobbler/collection.py", line 206, in add self.lite_sync.add_single_distro(ref.name) File "/usr/lib/python2.4/site-packages/cobbler/action_litesync.py", line 62, in add_single_distro self.sync.copy_single_distro_files(distro) File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py", line 319, in copy_single_distro_files utils.linkfile(kernel, os.path.join(distro_dir, b_kernel)) File "/usr/lib/python2.4/site-packages/cobbler/utils.py", line 561, in linkfile return utils.copyfile(src, dst) NameError: global name 'utils' is not defined Like I said, this new improvement in snippet handling greatly benefits us, and I'm really excited to be able to deploy it, hopefully soon (I'll wait until its available in the "stable" branch ... our cobbler server has become too important for me to screw up! :-) Thanks again, Michael! -s- From mmaccana at au1.ibm.com Mon Apr 14 00:31:58 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Mon, 14 Apr 2008 10:31:58 +1000 Subject: [et-mgmt-tools] VMM: Bad app name in about screen caused by deprecated property used in line 9 of vmm-about.glade Message-ID: <1208133118.13465.19.camel@mmaccana-laptop> Minor bug in the VMM 0.5.3 - about screen doesn't show proper name of app. Fix is: Virtual Machine Manager should read ? Virtual Machine Manager As 'name' is deprecated. Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From invite at goodtree.com Mon Apr 14 01:36:38 2008 From: invite at goodtree.com (Javier ivan Mendoza via GoodTree) Date: Sun, 13 Apr 2008 18:36:38 -0700 (PDT) Subject: [et-mgmt-tools] I gave your name... Message-ID: <20080414013638.8F6EE451C2E@web01.goodtree.com> http://goodtree.com/invitations/69492428?version=16&a=1530 Please accept my invitation to the website that is connecting all the good people around us. Be Good, Javier ivan --- This email sent by ivanhhn at yahoo.com through GoodTree LLC., 703 Market St. #470, San Francisco, CA 94103. No more invites, please: http://goodtree.com/opt_out?i=69492428&a=1530 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fcombernous at ares.fr Mon Apr 14 13:49:51 2008 From: fcombernous at ares.fr (Fabien COMBERNOUS) Date: Mon, 14 Apr 2008 15:49:51 +0200 Subject: [et-mgmt-tools] (no subject) Message-ID: <1208180991.480360ffa5da0@imp.free.fr> Hi, I'm testing libvirt (0.4.0) and virt-manager (0.5.3) with KVM. With the virt-manager i can run a vm with this command line : /usr/bin/kvm -M pc -m 128 -smp 1 -monitor pty -boot c -hda=/opt/vm/file_hda.img -hdb=/opt/vm/file_hdb.img -net nic,macaddr=00:16:3e:0f:d1:71,vlan=0 -net tap,fd=20,script=,vlan=0 -usb -vnc 127.0.0.1:2 But i don't want IDE. I want SCSI. So the command shoud be : /usr/bin/kvm -M pc -m 128 -smp 1 -monitor pty -boot c -drive file=/opt/vm/file_hda.img,if=scsi,bus=0,unit=3 -drive file=/opt/vm/file_hdb.img,if=scsi,bus=0,unit=5 -net nic,macaddr=00:16:3e:0f:d1:71,vlan=0 -net tap,fd=20,script=,vlan=0 -usb -vnc 127.0.0.1:2 What is the xml tags to use in /etc/libvirt/qemu/ xml files to get scsi devices ? Or is it possible directly with GUI ? P.S : My CPU is with VT enabled (vmx flag). Later. -- Fabien COMBERNOUS http://linux.ares.fr From mdehaan at redhat.com Mon Apr 14 14:48:24 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Apr 2008 10:48:24 -0400 Subject: [et-mgmt-tools] Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: <48036EB8.6080703@redhat.com> Sandor W. Sklar wrote: > > On Apr 11, 2008, at 1:05 PM, Michael DeHaan wrote: >> >> I've implemented this here -- with only a slight change to the way >> the above behavior works (basically there are no distro-overrides >> and the paths are slightly different): >> >> https://fedorahosted.org/cobbler/wiki/KickstartSnippets >> >> It's under the "Advanced Snippets" section and is available now in >> the git/devel branch. Testing welcome! > > I've tested this out with a fairly simple contrived example, and it > worked perfectly. I created the following files and directories: > > # find /var/lib/cobbler/snippets -type f > /var/lib/cobbler/snippets/packages > /var/lib/cobbler/snippets/post > /var/lib/cobbler/snippets/pre > /var/lib/cobbler/snippets/per_profile/packages/testprofile > /var/lib/cobbler/snippets/per_profile/post/testprofile > /var/lib/cobbler/snippets/per_profile/pre/testprofile I like the idea of the pre/post sections being subbed out. I didn't think of that :) > > > I created this profile: > > # cobbler profile report --name=testprofile > profile : testprofile > parent : rhel5Server-x86_64 > kickstart : /etc/cobbler/foo.ks > (... snip ...) > > And then added two system records: > > # cobbler system add --name=system1 --ip=172.24.10.10 > --mac="00:16:3e:43:22:02" --profile=rhel5Server-x86_64 > > # cobbler system add --name=system2 --ip=172.24.20.20 > --mac="00:16:3e:40:0a:a3" --profile=testprofile > > ... and ran "cobbler sync"; the rendered kickstarts in > /var/www/cobbler/kickstarts_sys/{system1,system2}/ks.cfg contained > exactly what I expected (system1's had the contents of > snippets/{packages,post,pre}, and system2's had the contents of > snippets/per_profile/{packages,post,pre}/testprofile.) > > This is a totally awesome improvement, and when the devel version is > ready for prime-time, it is going to make a *huge* difference in the > simplicity of our systems deployment. > > I've got a few comments about the testing process and some issues I > ran into; these comments shouldn't be construed as criticism, as I > expect most of those issues are of my own making or ignorance. That said: > > * I'd never used "git", nor installed it before. It took me a little > bit to figure out how to get it onto an RHEL5 system, but once I set > up the EPEL yum repo, it installed cleanly. The PatchProcess wiki page > helped immensely in getting going, but I think it would be useful to > have a "How to build a devel branch RPM on an RHEL5 system for > dummies" page (I'd be happy to write it, unless y'all think this is > something that shouldn't be in the wiki.) That sounds great to me! > > * The last version of cobbler I built (from the src.rpm) was 0.8.2. > Sometime between that version and the devel, a dependancy on the > python-ldap module was added. The RPM built, but all cobbler actions > failed with the traceback: > > ... (snip) > File "/usr/lib/python2.4/site-packages/cobbler/modules/authn_ldap.py", > line 20, in ? > import ldap > ImportError: No module named ldap > > > Perhaps I just missed something that stated that requirement. It would > be really nice, though, if those of us that have no use for the > authentication parts (ldap, for one) could disable it, perhaps with a > config variable like "use_ldap: 0". I'll add some code to keep that from being imported until it's needed. Thanks for the heads up. It won't require a config file setting. > > * This might be a known issue, but when I imported a distro ... > > # mount -o loop ./rhel-5.1-server-x86_64-dvd.iso /mnt > # cobbler import --path=/mnt --name=rhel5Server-x86_64 > > ... it ran fine, and then exited with the below traceback. The distro > appeared to suffer no ill effect from this error, or, at least it > worked for everything that I tested in this limited setup environment: > > NameError: global name 'utils' is not defined > I've been doing some reorganizing, I'll take a look at this and fix it if it's still present. > > Like I said, this new improvement in snippet handling greatly benefits > us, and I'm really excited to be able to deploy it, hopefully soon > (I'll wait until its available in the "stable" branch ... our cobbler > server has become too important for me to screw up! :-) Stable 1.0 should be out in about a month. There will be a test source rpm or two before then for people to test with and report bugs prior to things going into production repos. > > Thanks again, Michael! You're welcome! > > -s- > > > > > > > > > _______________________________________________ > 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 Mon Apr 14 14:52:10 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 14 Apr 2008 10:52:10 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <39d2723b0804120956o1e96d7e0s7a6bfd86d7e450dc@mail.gmail.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> <47FCE9E5.2070305@redhat.com> <39d2723b0804120956o1e96d7e0s7a6bfd86d7e450dc@mail.gmail.com> Message-ID: <48036F9A.6030908@redhat.com> Aaron Lippold wrote: > > > My thinking was to break them up into snippets then for the once I > could, define variables to make them more useful. > > What I liked about this was that I could then use the snippets in > other places. But perhaps puppet is a good choice or something like > it. Although one of the selling points I do want to try to keep is > that we are using base technology. I am hoping to keep my provisioning > and upkeep system as simple as possible. Sure. The above snippet system should work fine for what you want to do. Essentially the snippet insertion is done /before/ running things through Cheetah, so when given to Cheetah the templates look as if they were all part of one big file all along ... so if you do "#set foo = 'bar'" in one snippet (or in the master template), it's valid later on down the line. Presently you cannot have one snippet include other snippets through the Cobbler facility, though you can use Cheetah's built-in include if you need that. Cheetah includes require the usage of "#set global" for passing variables between includes. --Michael > > --Michael > > _______________________________________________ > 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 From crobinso at redhat.com Mon Apr 14 16:08:26 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 14 Apr 2008 12:08:26 -0400 Subject: [et-mgmt-tools] (no subject) In-Reply-To: <1208180991.480360ffa5da0@imp.free.fr> References: <1208180991.480360ffa5da0@imp.free.fr> Message-ID: <4803817A.2000705@redhat.com> Fabien COMBERNOUS wrote: > Hi, > > I'm testing libvirt (0.4.0) and virt-manager (0.5.3) with KVM. > With the virt-manager i can run a vm with this command line : > > /usr/bin/kvm -M pc -m 128 -smp 1 -monitor pty -boot c -hda=/opt/vm/file_hda.img > -hdb=/opt/vm/file_hdb.img -net nic,macaddr=00:16:3e:0f:d1:71,vlan=0 -net > tap,fd=20,script=,vlan=0 -usb -vnc 127.0.0.1:2 > > But i don't want IDE. I want SCSI. So the command shoud be : > > /usr/bin/kvm -M pc -m 128 -smp 1 -monitor pty -boot c -drive > file=/opt/vm/file_hda.img,if=scsi,bus=0,unit=3 -drive > file=/opt/vm/file_hdb.img,if=scsi,bus=0,unit=5 -net > nic,macaddr=00:16:3e:0f:d1:71,vlan=0 -net tap,fd=20,script=,vlan=0 -usb -vnc > 127.0.0.1:2 > > What is the xml tags to use in /etc/libvirt/qemu/ xml files to get scsi devices > ? Or is it possible directly with GUI ? > > P.S : My CPU is with VT enabled (vmx flag). > > Later. > > -- > Fabien COMBERNOUS > http://linux.ares.fr > There actually isn't support in libvirt yet for specifying scsi devices to qemu, so there is no applicable xml to give you that command line. If you could file a feature request in bugzilla against libvirt to help us keep track of it, it would be greatly appreciated. Thanks, Cole From mmaccana at au1.ibm.com Tue Apr 15 06:23:30 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Tue, 15 Apr 2008 16:23:30 +1000 Subject: [et-mgmt-tools] VMM using Tango icons! Message-ID: <1208240610.7867.21.camel@mmaccana-laptop> Hi all, I've modified VMM to use icons donated to the Tango project. Where's the best place to send diffs and icon files? I've also created a Wikipedia page for VMM - which so happens to have the Tango-ified version. See http://en.wikipedia.org/wiki/Virtual_Machine_Manager Are there any plans to create a proper icon for VMM itself? Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lippold at gmail.com Tue Apr 15 16:59:26 2008 From: lippold at gmail.com (Aaron Lippold) Date: Tue, 15 Apr 2008 12:59:26 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <48036F9A.6030908@redhat.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> <47FCE9E5.2070305@redhat.com> <39d2723b0804120956o1e96d7e0s7a6bfd86d7e450dc@mail.gmail.com> <48036F9A.6030908@redhat.com> Message-ID: <39d2723b0804150959n3b5073e2mb6e0f13839ccbd70@mail.gmail.com> Hello All, Thanks for the good feedback. It was good to have a new way to think about. So has the group talked about the line between provisioning and CM? I haven't found much online about when the business process moves from the provisioning architecture to the cm architecture. It might be a good thing to throw out to the list. This way we can at least have some basic structure so that, like my requests, we can evaluate which bucket they fall into. Yours, Aaron On Mon, Apr 14, 2008 at 10:52 AM, Michael DeHaan wrote: > Aaron Lippold wrote: > > > > > > > My thinking was to break them up into snippets then for the once I > > could, define variables to make them more useful. > > > > What I liked about this was that I could then use the snippets in other > > places. But perhaps puppet is a good choice or something like it. Although > > one of the selling points I do want to try to keep is that we are using base > > technology. I am hoping to keep my provisioning and upkeep system as simple > > as possible. > > > > Sure. The above snippet system should work fine for what you want to do. > Essentially the snippet insertion is done /before/ running things through > Cheetah, so when given to Cheetah the templates look as if they were all > part of one big file all along ... so if you do "#set foo = 'bar'" in one > snippet (or in the master template), it's valid later on down the line. > > Presently you cannot have one snippet include other snippets through the > Cobbler facility, though you can use Cheetah's built-in include if you need > that. Cheetah includes require the usage of "#set global" for passing > variables between includes. > > --Michael > > > > --Michael > > > > _______________________________________________ > > 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 > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Tue Apr 15 17:20:58 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 15 Apr 2008 13:20:58 -0400 Subject: [et-mgmt-tools] "Snippet Groups" In-Reply-To: <39d2723b0804150959n3b5073e2mb6e0f13839ccbd70@mail.gmail.com> References: <39d2723b0804061135t5b3d8e3dje6ddb0f2899722d4@mail.gmail.com> <47FA38FB.7060907@redhat.com> <39d2723b0804090005n1dc1575bg8fb5faeb22130a9a@mail.gmail.com> <47FCE9E5.2070305@redhat.com> <39d2723b0804120956o1e96d7e0s7a6bfd86d7e450dc@mail.gmail.com> <48036F9A.6030908@redhat.com> <39d2723b0804150959n3b5073e2mb6e0f13839ccbd70@mail.gmail.com> Message-ID: <4804E3FA.9030700@redhat.com> Aaron Lippold wrote: > Hello All, > > Thanks for the good feedback. It was good to have a new way to think > about. So has the group talked about the line between provisioning and > CM? I haven't found much online about when the business process moves > from the provisioning architecture to the cm architecture. It might be > a good thing to throw out to the list. Generally the idea is once you get to a certain level of complexity you will want to use kickstart for setting up your disks, repos, initial package lists, and bootstrapping your config management software, so that you can stop having to express your entire configuration in kickstart scripts or use less maintainable ways of pushing configuration files out. Config management systems tend to describe the way systems should "keep being", as opposed to actions that should just happen once. For instance, "this package should be installed at that version and this should be running". As an example, see https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem, which uses Cobbler's --ksmeta facility to indicate a mapping between a Cobbler profile and Puppet classes. That probably works similarly in other configuration management systems. Reviews and improvements to that doc are welcome as it's been a while since I tried that, and things may have changed with Puppet since. Contributions for how to integrate Cobbler with other config management systems are welcome too. We can probably do some work to make that easier in a future release if there is a lot of interest in this, though one will never require the other. In general, we don't want to explicitly link certain config management tools with certain provisioning tools and vice versa, as part of the power of smaller, lightweight tools is being able to swap things in and out, and also being able to use one without the other when you are starting out. Things are more flexible that way. All it really takes to integrate them is a little magic in your kickstart file and a Cobbler --ksmeta parameter. This means that you can assign a webservers profile to a few config management classes, and a specific server, if you want, to one more in addition to what the profile is assigned to. (For instance, a server could be a "webserver" profile but also be assigned to a class that dealt with something hardware/system specific). --Michael > > This way we can at least have some basic structure so that, like my > requests, we can evaluate which bucket they fall into. There are no buckets, it's more of a large sandbox :) --Michael > > Yours, > > Aaron > > On Mon, Apr 14, 2008 at 10:52 AM, Michael DeHaan > wrote: > > Aaron Lippold wrote: > > > > My thinking was to break them up into snippets then for the > once I could, define variables to make them more useful. > > What I liked about this was that I could then use the snippets > in other places. But perhaps puppet is a good choice or > something like it. Although one of the selling points I do > want to try to keep is that we are using base technology. I am > hoping to keep my provisioning and upkeep system as simple as > possible. > > > Sure. The above snippet system should work fine for what you > want to do. Essentially the snippet insertion is done /before/ > running things through Cheetah, so when given to Cheetah the > templates look as if they were all part of one big file all along > ... so if you do "#set foo = 'bar'" in one snippet (or in the > master template), it's valid later on down the line. > > Presently you cannot have one snippet include other snippets > through the Cobbler facility, though you can use Cheetah's > built-in include if you need that. Cheetah includes require the > usage of "#set global" for passing variables between includes. > > --Michael > > > --Michael > > _______________________________________________ > 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 > > > _______________________________________________ > 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 From rjones at redhat.com Tue Apr 15 17:35:30 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 15 Apr 2008 18:35:30 +0100 Subject: [et-mgmt-tools] VMM using Tango icons! In-Reply-To: <1208240610.7867.21.camel@mmaccana-laptop> References: <1208240610.7867.21.camel@mmaccana-laptop> Message-ID: <20080415173530.GA25301@amd.home.annexia.org> On Tue, Apr 15, 2008 at 04:23:30PM +1000, Mike MacCana wrote: > I've modified VMM to use icons donated to the Tango project. Where's the > best place to send diffs and icon files? You can post patches / files here. (If the icon files are large & binary then I guess we'd prefer a link rather than an attachment). I have no idea how we deal with themes. I'm assuming by 'Tango project' you mean this: http://tango.freedesktop.org/Tango_Desktop_Project [...] > Are there any plans to create a proper icon for VMM itself? Fedora have a desktop icon for VMM. Can't recall off-hand if it is included in the virt-manager tarball, but it probably ought to be if not. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From bstein at redhat.com Tue Apr 15 18:13:31 2008 From: bstein at redhat.com (Brian Stein) Date: Tue, 15 Apr 2008 14:13:31 -0400 Subject: [et-mgmt-tools] VMM using Tango icons! In-Reply-To: <1208240610.7867.21.camel@mmaccana-laptop> References: <1208240610.7867.21.camel@mmaccana-laptop> Message-ID: <4804F04B.3020809@redhat.com> Mike MacCana wrote: > Hi all, > > I've modified VMM to use icons donated to the Tango project. Where's the > best place to send diffs and icon files? > > I've also created a Wikipedia page for VMM - which so happens to have > the Tango-ified version. See > http://en.wikipedia.org/wiki/Virtual_Machine_Manager > > Are there any plans to create a proper icon for VMM itself? There are ... it's planned for a post F9 release. > ________________________________________________ > Mike MacCana > Technical Specialist > Linux Services > > IBM Global Services > Level 14, 60 City Rd > Southgate Vic 3000 > > Phone: +61-3-8656-2138 > Fax: +61-4-?8656-2423 > Email: mmaccana at au1.ibm.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From berrange at redhat.com Tue Apr 15 18:18:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 15 Apr 2008 19:18:03 +0100 Subject: [et-mgmt-tools] VMM using Tango icons! In-Reply-To: <1208240610.7867.21.camel@mmaccana-laptop> References: <1208240610.7867.21.camel@mmaccana-laptop> Message-ID: <20080415181803.GA14463@redhat.com> On Tue, Apr 15, 2008 at 04:23:30PM +1000, Mike MacCana wrote: > Hi all, > > I've modified VMM to use icons donated to the Tango project. Where's the > best place to send diffs and icon files? To be honest the choice of icon themes is a distribution specific integration problem. Some distros use Tango, some don't. So changing virt-manager to use Tango isn't a net win - it just shifts work from one distro another. Feel free to add a page to the wiki site at http://virt-manager.org linking to your Tango icons though, so people who are interested can easily get hold of them. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Tue Apr 15 21:55:31 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 15 Apr 2008 17:55:31 -0400 Subject: [et-mgmt-tools] Cobbler kerberos support testing (& other 1.0 notes/ramblings) Message-ID: <48052453.2080802@redhat.com> Hello Cobbler land, I wanted to give a quick update on some things going on in Cobbler development. So far the 0.9.X branch is coming along very nicely and the changelog is already quite large. A lot of this can use testing now and will help us get a much nicer release out earlier. Of particular interest: Kerberos added yesterday. It's an optional authentication mode, and if anyone wants to test it see the following: https://fedorahosted.org/cobbler/wiki/CobblerWithKerberos This feature pretty much relies on Apache to get things done and should be pretty easy to set up if you already have a Kerberos Apache config for another application. As always, the default out-of-the-box configuration is the simple config file (digest) based one, so Kerberos will not be required for a Cobbler setup in any case. (Slightly related -- We've also talked about doing LDAP authorization in addition to authentication for a future release --f or those who want to control ownership but don't want to use the config file). I'm also working on updating the Cobbler "status" command (which has been pretty weak for a while) for the 0.9/1.0 release. This feature will now log the IP/MAC and profile/system names of any provisioning requests, so you'll be able to see what a particular ip/mac is installed to, even if it's not in your Cobbler "database", and when it was last installed. For installing systems, you'll also be able to see how long they have been installing. This will be much better than the existing status implementation, which relies on Apache logs and isn't very accurate when it tries to determine when things happened (when it works). We'll continue to log syslog for distros that support it as well. There have also been some good ideas on IRC over the last few days about improving the WebUI to better deal with the ownership modes. A couple of those ideas including offering a simpler webui view for "lowly users" that only allow them to edit select fields of what they own -- for instance, they can see they own profile X and Y, and systems A, B, and C, and can choose to flip the netboot flags of system C and reinstall it if they wish, etc. Another thing we'll likely want to add is search to the WebUI, so if you have a very large number of systems, and just want to find out what a particular hostname/ip/mac is running, it will be quick to do that. The final thing that I want to address for the WebUI for 0.9/1.0 is being able to create/copy kickstart templates as opposed to just being able to edit them. That should round out the webapp a good bit. Other ideas welcome. Surfacing cobbler status is probably also a good idea, especially if we can find a nice way to show the "last installed date" for systems and other neat stuff like that. I also want to look at ACLs and running Cobbler as non-root (possibly) though that may be a later release depending on how development goes, probably a quick 1.1/1.2 release. Anyhow, if you have a kerberos setup and don't mind playing with git (see the first parts of https://fedorahosted.org/cobbler/wiki/PatchProcess) -- testing is very welcome. The latest version of the rest of the development changelog is always available here: http://git.fedorahosted.org/git/?p=cobbler;a=blob_plain;f=CHANGELOG;hb=devel And as always, other comments about what you'd like to see in Cobbler are always welcome to. We have an RFE list in Trac for holding the ideas. If you don't have a Trac account you can get one at https://admin.fedoraproject.org/accounts and Trac is here: https://fedorahosted.org/cobbler/report Thanks! --Michael From Pablo.Iranzo at redhat.com Tue Apr 15 23:03:28 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Wed, 16 Apr 2008 01:03:28 +0200 (CEST) Subject: [et-mgmt-tools] Cobbler GIT: patch for autodetection of arch during import Message-ID: Hi all Attached is a patch for your reviewing pleasure that checks for arch in "--mirror" url so if you don't set it using --arch, it tries to autodetect it. Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? -------------- next part -------------- A non-text attachment was scrubbed... Name: cobbler_import_arch.diff Type: text/x-diff Size: 979 bytes Desc: URL: From robin-lists at robinbowes.com Wed Apr 16 00:25:03 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 16 Apr 2008 01:25:03 +0100 Subject: [et-mgmt-tools] Re: Cobbler kerberos support testing (& other 1.0 notes/ramblings) In-Reply-To: <48052453.2080802@redhat.com> References: <48052453.2080802@redhat.com> Message-ID: Michael DeHaan wrote: > We've also talked about doing LDAP authorization in addition to > authentication for a future release --f or those who want to control > ownership but don't want to use the config file). I'd be very interested in this sort of thing. One use-case I'm thinking about is for an ISP with several clients allowing each client to use cobbler to do their own installs. Of course, this would require a further degree of privacy, i.e. it would be necessary to prevent client A seeing anything belonging to Client B, and vice versa. Some things should be viewable (read-only) to all, e.g. a standard RHEL5 profile. Clients could perhaps copy a read-only profile to their own custom profile and modify it as required. Of course, another option is to restrict cobbler access to ISP employees thus eliminating the need for strict partitioning. Anyway, the LDAP authorisation sounds like interesting stuff - I certainly wouldn't want to have to maintain an LDAP directory for authentication, then manually edit a file to control authorisation. Cheers, R. From robin-lists at robinbowes.com Wed Apr 16 01:46:39 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 16 Apr 2008 02:46:39 +0100 Subject: [et-mgmt-tools] Re: Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: Sandor W. Sklar wrote: > ... but I think it would be useful to have a "How to build a devel > branch RPM on an RHEL5 system for dummies" page (I'd be happy to > write it, unless y'all think this is something that shouldn't be in > the wiki.) +1 for that. I'm at the stage where I want to try out some of the new features in the dev. version, but would like to use RPMs. I'm relatively experienced in building RPMs, but it would be nice to not have to work it out myself! :) It would be doubly nice to be able to do something like "make rpm" from the git checkout!! :) :) R. From ssklar at stanford.edu Wed Apr 16 04:36:32 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Tue, 15 Apr 2008 21:36:32 -0700 Subject: [et-mgmt-tools] Re: Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: <7DFDEC37-7A43-4159-ACD8-CC5C2DF1D20C@stanford.edu> On Apr 15, 2008, at 6:46 PM, Robin Bowes wrote: > Sandor W. Sklar wrote: >> ... but I think it would be useful to have a "How to build a devel >> branch RPM on an RHEL5 system for dummies" page (I'd be happy to >> write it, unless y'all think this is something that shouldn't be in >> the wiki.) > > +1 for that. > > I'm at the stage where I want to try out some of the new features in > the dev. version, but would like to use RPMs. > > I'm relatively experienced in building RPMs, but it would be nice to > not have to work it out myself! :) > > It would be doubly nice to be able to do something like "make rpm" > from the git checkout!! :) :) I'll try to get my write-up posted in the next day or two. Like most things, it really wasn't that difficult, once you know how to do it. :-) And, in fact, the build process results in an RPM that you then just install normally! -s- From mdehaan at redhat.com Wed Apr 16 14:52:12 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Apr 2008 10:52:12 -0400 Subject: [et-mgmt-tools] Cobbler GIT: patch for autodetection of arch during import In-Reply-To: References: Message-ID: <4806129C.6040304@redhat.com> Pablo Iranzo G?mez wrote: > Hi all > Attached is a patch for your reviewing pleasure that checks for > arch in "--mirror" url so if you don't set it using --arch, it tries to > autodetect it. > > Regards > Pablo > There's already some auto-detection code for action_import.py ... there was an open ticket open to add automatic arch detection for repos though, in a very similar way. I thought you were adding that one. (The --arch on "repo add" is there so yum's reposync can download packages that differ from the local base arch) Doing the check before if we can find it in the URL does make sense though, as it prevents the need to do the scan. I'll add this and see if I can't do similar for "repo add". Thanks! --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 Apr 16 15:00:32 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Apr 2008 11:00:32 -0400 Subject: [et-mgmt-tools] Cobbler GIT: patch for autodetection of arch during import In-Reply-To: References: Message-ID: <48061490.1050208@redhat.com> Pablo Iranzo G?mez wrote: > Hi all > Attached is a patch for your reviewing pleasure that checks for > arch in "--mirror" url so if you don't set it using --arch, it tries to > autodetect it. > > Regards > Pablo > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools This appears to break slightly when the URL does not contain the arch segment, which we want to allow, because if you have a mirror with multiple distros, we want to be able to pull them in all at once. That's why the detection is later on. I'm still interested in that auto-detection for "repo add" as that will eliminate some user confusion for sure. Thanks! From Pablo.Iranzo at redhat.com Wed Apr 16 15:12:21 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Wed, 16 Apr 2008 17:12:21 +0200 Subject: [et-mgmt-tools] Cobbler GIT: patch for autodetection of arch during import In-Reply-To: <48061490.1050208@redhat.com> References: <48061490.1050208@redhat.com> Message-ID: <1208358741.4990.65.camel@iranzo.users.redhat.com> Will check later and resend, Thanks for the feedback! Pablo El mi?, 16-04-2008 a las 11:00 -0400, Michael DeHaan escribi?: > Pablo Iranzo G?mez wrote: > > Hi all > > Attached is a patch for your reviewing pleasure that checks for > > arch in "--mirror" url so if you don't set it using --arch, it tries to > > autodetect it. > > > > Regards > > Pablo > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > This appears to break slightly when the URL does not contain the arch > segment, which we want to allow, because if you have a mirror with > multiple distros, we want to be able to pull them in all at once. > That's why the detection is later on. > > I'm still interested in that auto-detection for "repo add" as that will > eliminate some user confusion for sure. > > Thanks! > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From mdehaan at redhat.com Wed Apr 16 15:11:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 16 Apr 2008 11:11:52 -0400 Subject: [et-mgmt-tools] Re: Looping through possibilities in a "snippet" In-Reply-To: References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> Message-ID: <48061738.70406@redhat.com> Robin Bowes wrote: > Sandor W. Sklar wrote: >> ... but I think it would be useful to have a "How to build a devel >> branch RPM on an RHEL5 system for dummies" page (I'd be happy to >> write it, unless y'all think this is something that shouldn't be in >> the wiki.) > > +1 for that. > > I'm at the stage where I want to try out some of the new features in > the dev. version, but would like to use RPMs. > > I'm relatively experienced in building RPMs, but it would be nice to > not have to work it out myself! :) > > It would be doubly nice to be able to do something like "make rpm" > from the git checkout!! :) :) > > R. You can. The basic short instructions are, "follow the git checkout steps", and then run "make". Make will generate both the source and noarch RPMs for you, with no arguments. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From ssklar at stanford.edu Wed Apr 16 16:15:01 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Wed, 16 Apr 2008 09:15:01 -0700 Subject: [et-mgmt-tools] Re: Looping through possibilities in a "snippet" In-Reply-To: <48061738.70406@redhat.com> References: <290786FA-0DA0-489B-9B48-BDFFD14E30F6@stanford.edu> <47FA40DE.2080504@redhat.com> <47FA483A.2040401@redhat.com> <2CA47409-EBA0-462D-ABD4-274CACA7FBC7@stanford.edu> <47FA62B3.2050309@redhat.com> <47FFC47E.6010400@redhat.com> <48061738.70406@redhat.com> Message-ID: <41B8D5B6-1F8F-44A7-BA87-63587775E3DC@stanford.edu> On Apr 16, 2008, at 8:11 AM, Michael DeHaan wrote: > Robin Bowes wrote: >> Sandor W. Sklar wrote: >>> ... but I think it would be useful to have a "How to build a devel >>> branch RPM on an RHEL5 system for dummies" page (I'd be happy to >>> write it, unless y'all think this is something that shouldn't be in >>> the wiki.) >> >> +1 for that. >> >> I'm at the stage where I want to try out some of the new features >> in the dev. version, but would like to use RPMs. >> >> I'm relatively experienced in building RPMs, but it would be nice >> to not have to work it out myself! :) >> >> It would be doubly nice to be able to do something like "make rpm" >> from the git checkout!! :) :) >> >> R. > > > You can. > > The basic short instructions are, "follow the git checkout steps", > and then run "make". Make will generate both the source > and noarch RPMs for you, with no arguments. I've added this page ... ... which is short and direct. It took me 10 minutes to write it, but about two hours to figure it out, so perhaps it is of benefit to others. :-) -s- From agoodall at rm.com Thu Apr 17 11:41:57 2008 From: agoodall at rm.com (Adam Goodall) Date: Thu, 17 Apr 2008 12:41:57 +0100 Subject: [et-mgmt-tools] cobbler reposync with different arch Message-ID: <62E8616DA7F577429A29CFD86648DA3C1F3F47@mail02.internal.rmplc.net> All I'm having trouble getting cobbler to sync packages for an arch that is different to the cobbler servers own. I have cobbler running on an i386 box and for one of the repos I'm mirroring I want to pull down x86_64. However when the repository syncs down it will only pull the noarch RPM's and completely ignores the x86_64 ones. I have the correct arch set for the repo as is shown in the output of cobbler repo report: repo : dag-EL4-x86_64 mirror : http://apt.sw.be/redhat/el4/en/x86_64/rpmforge/ keep updated : True priority : 99 rpm list : ['nagios-plugins', 'nagios-nrpe', 'zonecheck'] createrepo_flags : -c cache arch : x86_64 yum options : {} In this example the zonecheck rpm (which is noarch) is pulled but the two nagios rpm's are ignored.: # cobbler reposync --only=dag-EL4-x86_64 - creating: /var/www/cobbler/repo_mirror/.origin/dag-EL4-x86_64.repo - /usr/bin/yumdownloader --resolve -c /var/www/cobbler/repo_mirror/.origin/dag-EL4-x86_64.repo --destdir=/var/www/cobbler/repo_mirror/dag-EL4-x86_64 nagios-plugins nagios-nrpe zonecheck No Match for argument nagios-plugins No Match for argument nagios-nrpe /var/www/cobbler/repo_mirror/dag-EL4-x86_64/zonecheck-2.0.4-1.2.el4.rf.n oarch.rpm already exists and appears to be complete - createrepo -c cache /var/www/cobbler/repo_mirror/dag-EL4-x86_64 1/1 - zonecheck-2.0.4-1.2.el4.rf.noarch.rpm Saving Primary metadata Saving file lists metadata Saving other metadata - creating: /var/www/cobbler/repo_mirror/dag-EL4-x86_64/config.repo Does anyone have any ideas where im going wrong or what I need to do to make it work? If it helps I'm running on RHEL5 with the following versions: # rpm -qa| egrep -i "cobbler|yum" yum-utils-1.0.4-3.el5 yum-updatesd-3.0.1-5.el5 yum-rhn-plugin-0.5.2-5.el5_1.2 yum-3.0.1-5.el5 yum-security-1.0.4-3.el5 cobbler-0.8.2-1.el5 yum-metadata-parser-1.0-8.fc6 Thanks Adam ______________________________________________________________________ You might be interested in this... Find out what funding is available for schools in England over the next three years: http://www.rm.com/funding ______________________________________________________________________ P.S. Think Green - don't print this email unless you really need to. This message is confidential, so please treat it appropriately and for its intended purpose only. In particular, if it refers to any technical data, terms or prices not generally available or known, such items are "commercially sensitive information" within the terms of the Freedom of Information Act 2000 and related laws. As it would be prejudicial to RM's commercial interests if these were disclosed, please refrain from doing so. As Internet communications are not secure, please be aware that RM cannot accept responsibility for its contents. Any views or opinions presented are those of the author only and not of RM. If you are not the intended recipient of this e-mail, please accept our apologies and arrange for copies of it to be deleted. For your information, RM may intercept incoming and outgoing email communications. RM Education plc Registered Office: New Mill House, 183 Milton Park, Abingdon, Oxfordshire, OX14 4SE, England Registered Number: 1148594 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjones at redhat.com Thu Apr 17 14:11:54 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 17 Apr 2008 15:11:54 +0100 Subject: [et-mgmt-tools] ANNOUNCE: virt-df ('df' for guests) now supports LVM Message-ID: <20080417141154.GA18657@amd.home.annexia.org> I'm happy to say that virt-df, the command-line 'df'-like tool for looking at disk usage of guests, now supports LVM, making it usable for the majority of situations where your guests are running Linux distributions. You can now run 'virt-df' on the host and display the disk space used/available on all filesystems of all your guests. There is no need to run anything inside the guest. Here is an example with two running domains: # virt-df -c qemu:///system -h Filesystem Size Used Available Type rhel51x32kvm:hda1 96.8 MiB 14.6 MiB 82.2 MiB Linux ext2/3 rhel51x32kvm:VolGroup00/LogVol00 6.4 GiB 3.6 GiB 2.8 GiB Linux ext2/3 rhel51x32kvm:VolGroup00/LogVol01 992.0 MiB Linux swap rhel51x64kvm:hda1 96.8 MiB 22.1 MiB 74.7 MiB Linux ext2/3 rhel51x64kvm:VolGroup00/LogVol00 6.4 GiB 3.2 GiB 3.2 GiB Linux ext2/3 rhel51x64kvm:VolGroup00/LogVol01 992.0 MiB Linux swap Home page: http://et.redhat.com/~rjones/virt-df/ Source and binaries from: http://et.redhat.com/~rjones/virt-df/files/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From robin-lists at robinbowes.com Thu Apr 17 15:19:07 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Thu, 17 Apr 2008 16:19:07 +0100 Subject: [et-mgmt-tools] virt-p2v - does it support md and lvm Message-ID: Hi, Does virt-p2v support LVM? The reason I ask is that I recently tried to migrate a FC4 machine to a guest and it failed. The machine disk configuration is as follows: - two physical disks - Each disk has two partitions of type "Linux raid autodetect" - md0 is made up of /dev/hde1 & /dev/hdf1 - md1 is made up of /dev/hde2 and /dev/hdf2 - md0 is used as /boot - md1 is an LVM PV. - All the PV is allocated to a VG named "VolGroup00" - The system file systems are LVs in VolGroup00: lv_home VolGroup00 -wi-ao 5.00G lv_root VolGroup00 -wi-ao 1.00G lv_swap_01 VolGroup00 -wi-ao 1.50G lv_usr VolGroup00 -wi-ao 5.00G lv_var VolGroup00 -wi-ao 61.88G When asked to choose the partition containing the root fs, it showed me two partitions, both labeled as "unknown". Will the configuration work? Or does virt-2pv not support it? R. From rjones at redhat.com Thu Apr 17 15:21:44 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 17 Apr 2008 16:21:44 +0100 Subject: [et-mgmt-tools] virt-p2v - does it support md and lvm In-Reply-To: References: Message-ID: <20080417152144.GA21438@amd.home.annexia.org> On Thu, Apr 17, 2008 at 04:19:07PM +0100, Robin Bowes wrote: > Does virt-p2v support LVM? The reason I ask is that I recently tried to > migrate a FC4 machine to a guest and it failed. LVM - yes. md (RAID) obviously not, but I'm not quite sure why. It relies on the kernel to reconstruct RAID arrays and such like. Could you send me the output of 'dmesg' and '/tmp/virt-p2v.log' from that machine? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From dlutter at redhat.com Thu Apr 17 20:07:34 2008 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 17 Apr 2008 13:07:34 -0700 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API Message-ID: <1208462854.24126.53.camel@localhost.localdomain> I am pleased to announce a new configuration management project: Augeas, a low-level configuration API and editing tool. Augeas' main goal is to make programmatic changes of configuration data on Linux/Unix systems simple and safe. The main stumbling stone for this is that configuration data is stored in numerous files in widely varying formats. This is both next to impossible to change and is valuable in many situations. Rather than demanding a radical change, Augeas adapts to this reality. Augeas parses configuration files in their native formats and transforms them into a tree. Configuration changes are made by manipulating this tree and saving it back into native config files (/etc/hosts, /etc/grub.conf, ...). The tree abstracts away all the pesky details that make editing config files with grep/sed/awk so challenging, and exposes config data uniformly, regardless of the format in which it is actually stored. With this approach, the programs/daemons relying on config files continue to work as they do today, and editing config files with Augeas can be interleaved with changing them by other means, from vi to existing perl scripts. What is it ? ============ Augeas consists of a C library and API, a command line tool to manipulate configuration from the shell, and language bindings for Ruby and Python. The file <-> tree transformations are driven by schema descriptions, one for each file format. Schemas essentially consist of regular expressions describing the file structure and instructions on how to map matches into the tree. The hope is that over time, the set of schemas becomes both complete and sufficiently widespread to provide a canonical tree view of common configuration data. Where can I find Augeas ======================= Augeas' website is http://augeas.net/ Downloads can be found at http://augeas.net/download/ To learn more, start with the introductory tour at http://augeas.net/tour.html Discussions around Augeas happen on augeas-devel, https://www.redhat.com/mailman/listinfo/augeas-devel Help wanted =========== Augeas is a reasonable proof-of-concept as of now; there are lots of things that need to be done, and that I would love for others to pitch in. Some of them are listed in the todo list at http://augeas.net/todo.html The most pressing issues right now though are * Enable your favorite config mgmt tool to use Augeas as the low-level config editing tool * Cover more config files and write schemes for them; even without writing actual schema, a discussion on augeas-devel on how config file X would best be mapped into the tree would be really useful. * Anything to improve the quality of the current implementation; I know I cut some corners in the initial implementation, and any review/patches to improve it would be useful. David From mmaccana at au1.ibm.com Fri Apr 18 02:02:15 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Fri, 18 Apr 2008 12:02:15 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208462854.24126.53.camel@localhost.localdomain> References: <1208462854.24126.53.camel@localhost.localdomain> Message-ID: <1208484135.7867.173.camel@mmaccana-laptop> On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote: > I am pleased to announce a new configuration management project: Augeas, > a low-level configuration API and editing tool. > > Augeas' main goal is to make programmatic changes of configuration data > on Linux/Unix systems simple and safe. The main stumbling stone for this > is that configuration data is stored in numerous files in widely varying > formats. This is both next to impossible to change and is valuable in > many situations. ?The amount of effort spent creating and re-creating tools to parse, edit and transform a variety of unnecessary, unstructured data formats over the last 30 years, and to continue doing this for the next 10 years, is less than that required to: * write an RFC for a standard format * create patches to applications to support that format * create an editor for that format (which handles data - settings, values, parents and children, rather than presentation related info like lines and paragraph) * package those changes in a distribution Using 'widely varying formats' is not 'valuable'. It's an unfortunate accident that wastes everyone's time with various horrible bandaid solutions, and occasionally makes destroying user data an 'accepted limitation' of tools like system-config-named. Mike > Rather than demanding a radical change, Augeas adapts > to this reality. > > Augeas parses configuration files in their native formats and transforms > them into a tree. Configuration changes are made by manipulating this > tree and saving it back into native config files > (/etc/hosts, /etc/grub.conf, ...). > > The tree abstracts away all the pesky details that make editing config > files with grep/sed/awk so challenging, and exposes config data > uniformly, regardless of the format in which it is actually stored. With > this approach, the programs/daemons relying on config files continue to > work as they do today, and editing config files with Augeas can be > interleaved with changing them by other means, from vi to existing perl > scripts. > > What is it ? > ============ > > Augeas consists of a C library and API, a command line tool to > manipulate configuration from the shell, and language bindings for Ruby > and Python. The file <-> tree transformations are driven by schema > descriptions, one for each file format. Schemas essentially consist of > regular expressions describing the file structure and instructions on > how to map matches into the tree. The hope is that over time, the set of > schemas becomes both complete and sufficiently widespread to provide a > canonical tree view of common configuration data. > > Where can I find Augeas > ======================= > > Augeas' website is http://augeas.net/ > Downloads can be found at http://augeas.net/download/ > To learn more, start with the introductory tour at http://augeas.net/tour.html > Discussions around Augeas happen on augeas-devel, > https://www.redhat.com/mailman/listinfo/augeas-devel > > Help wanted > =========== > > Augeas is a reasonable proof-of-concept as of now; there are lots of > things that need to be done, and that I would love for others to pitch > in. Some of them are listed in the todo list at > http://augeas.net/todo.html > > The most pressing issues right now though are > > * Enable your favorite config mgmt tool to use Augeas as the > low-level config editing tool > * Cover more config files and write schemes for them; even without > writing actual schema, a discussion on augeas-devel on how > config file X would best be mapped into the tree would be really > useful. > * Anything to improve the quality of the current implementation; I > know I cut some corners in the initial implementation, and any > review/patches to improve it would be useful. > > David > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooge at gmail.com Fri Apr 18 03:17:40 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Thu, 17 Apr 2008 21:17:40 -0600 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208484135.7867.173.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> Message-ID: <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> On Thu, Apr 17, 2008 at 8:02 PM, Mike MacCana wrote: > > On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote: > I am pleased to announce a new configuration management project: Augeas, > a low-level configuration API and editing tool. > > Augeas' main goal is to make programmatic changes of configuration data > on Linux/Unix systems simple and safe. The main stumbling stone for this > is that configuration data is stored in numerous files in widely varying > formats. This is both next to impossible to change and is valuable in > many situations. > > ?The amount of effort spent creating and re-creating tools to parse, edit > and transform a variety of unnecessary, unstructured data formats over the > last 30 years, and to continue doing this for the next 10 years, is less > than that required to: > Then it should have happened.. because we have had several million monkeys doing various things. I have seen multiple attempts at what you outline, but because they are expressing what a person wants something to be you end up with the effects of the tower of Babyl when few people can understand what the other person is saying. > * write an RFC for a standard format You forgot the step: Argue about every 3rd line in the RFC and end up with various versions that all state they meet the RFC but do not interact with each other.. HTML-2.0 wasn't hard to write to.. but no one ever did it the same way. > > * create patches to applications to support that format > > * create an editor for that format (which handles data - settings, values, > parents and children, rather than presentation related info like lines and > paragraph) > > * package those changes in a distribution > > Using 'widely varying formats' is not 'valuable'. It's an unfortunate > accident that wastes everyone's time with various horrible bandaid > solutions, and occasionally makes destroying user data an 'accepted > limitation' of tools like system-config-named. > -- 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 mmaccana at au1.ibm.com Fri Apr 18 03:39:06 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Fri, 18 Apr 2008 13:39:06 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> Message-ID: <1208489946.7867.178.camel@mmaccana-laptop> On Thu, 2008-04-17 at 21:17 -0600, Stephen John Smoogen wrote: > On Thu, Apr 17, 2008 at 8:02 PM, Mike MacCana wrote: > > > > On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote: > > I am pleased to announce a new configuration management project: Augeas, > > a low-level configuration API and editing tool. > > > > Augeas' main goal is to make programmatic changes of configuration data > > on Linux/Unix systems simple and safe. The main stumbling stone for this > > is that configuration data is stored in numerous files in widely varying > > formats. This is both next to impossible to change and is valuable in > > many situations. > > > > ?The amount of effort spent creating and re-creating tools to parse, edit > > and transform a variety of unnecessary, unstructured data formats over the > > last 30 years, and to continue doing this for the next 10 years, is less > > than that required to: > > (create a standard format, proactively patch apps to support a standard format, make an editor for that format, and start shipping packages) > > Then it should have happened.. because we have had several million > monkeys doing various things. I have seen multiple attempts at what > you outline, When? The closest thing I've ever seen has been gconf and dconf, which are limited to GNOME apps (albeit quite successful). Mike Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin-lists at robinbowes.com Fri Apr 18 08:46:49 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Fri, 18 Apr 2008 09:46:49 +0100 Subject: [et-mgmt-tools] Re: virt-p2v - does it support md and lvm In-Reply-To: <20080417152144.GA21438@amd.home.annexia.org> References: <20080417152144.GA21438@amd.home.annexia.org> Message-ID: Richard W.M. Jones wrote: > On Thu, Apr 17, 2008 at 04:19:07PM +0100, Robin Bowes wrote: >> Does virt-p2v support LVM? The reason I ask is that I recently tried to >> migrate a FC4 machine to a guest and it failed. > > LVM - yes. > > md (RAID) obviously not, but I'm not quite sure why. It relies on the > kernel to reconstruct RAID arrays and such like. Could you send me > the output of 'dmesg' and '/tmp/virt-p2v.log' from that machine? Done. R. From berrange at redhat.com Fri Apr 18 14:01:43 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 18 Apr 2008 15:01:43 +0100 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208489946.7867.178.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> <1208489946.7867.178.camel@mmaccana-laptop> Message-ID: <20080418140143.GC28962@redhat.com> On Fri, Apr 18, 2008 at 01:39:06PM +1000, Mike MacCana wrote: > On Thu, 2008-04-17 at 21:17 -0600, Stephen John Smoogen wrote: > > > On Thu, Apr 17, 2008 at 8:02 PM, Mike MacCana wrote: > > > > > > On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote: > > > I am pleased to announce a new configuration management project: Augeas, > > > a low-level configuration API and editing tool. > > > > > > Augeas' main goal is to make programmatic changes of configuration data > > > on Linux/Unix systems simple and safe. The main stumbling stone for this > > > is that configuration data is stored in numerous files in widely varying > > > formats. This is both next to impossible to change and is valuable in > > > many situations. > > > > > > ???The amount of effort spent creating and re-creating tools to parse, edit > > > and transform a variety of unnecessary, unstructured data formats over the > > > last 30 years, and to continue doing this for the next 10 years, is less > > > than that required to: > > > > > (create a standard format, proactively patch apps to support a standard > format, make an editor for that format, and start shipping packages) Back in the real world people also want to be able to manage existing deployed production applications today. Even if you convince upstream to adopt your grand unified configuration scheme, it'll take a seriously long time before all applications you care about managing are changed & filter down into real world deployed OS. And then there are all the closed source applications which you have no control over. So even if everyone agreed to use a standard configuration format, exceedingly unlikely, there'd still be a huge set of existing applications to managed with a tool like Augeas. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Fri Apr 18 16:22:28 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 12:22:28 -0400 Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth Message-ID: <4808CAC4.9020908@redhat.com> Hi folks, So earlier I wrote about some ideas around automatically registering systems when Cobbler sees them, and I wrote up some example scripts for usage by the FreeLinuxPC guys. To me, this seems pretty compelling as you wouldn't have to manually build up a list of every MAC address in your data center and so on. It turns out some of the mac data I was relying on isn't present, so this didn't work as well as I thought it did -- but -- good news -- I can fix it. So since I need to fix this, and wanted to bounce some ideas off everyone and find out if this would be useful or not. It seems useful to me anyway, at least as a configuration option. The idea -- all kickstart requests through cobbler will now go through a cgi (or more likely, a new mod python piece for performance reasons) that will serve up the kickstart file for all cobbler-hosted kickstart files. Then, we have the configuration ability to automatically add new system objects (correctly configured to the proper profile) when they get installed. Since we are also doing this via a web script, we can also decide to re-evaluate the templates at runtime, effectively eliminating the need for "cobbler sync" for anything but regenerating DNS/DHCP. For an example of the registration case -- if you tftpboot 500 new systems ("straight off the truck"), and you use the PXE menu to assign some to "webservers" and some to "dbservers", this reorganization of how we do things would allow us to auto-create system records, correctly assigned to the profile they were assigned to, with the MAC data already filled in. For security reasons, this would only add new system records if the objects were not already there. Due to various catch-22's, if you add a new system this way, and then reinstall it using the PXE menus, we can't have it update the profile associations in cobbler. However -- you wouldn't need to do this, because you could do something as simple as: cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1 (and cycle power) in order to do reinstalls. This seems to be a nice solution for logging the profiles and mac info at first install time and saves some data entry. (and yes, we'll have a setting to turn this off). Thoughts on this and on install time template evaluation? --Michael From mdehaan at redhat.com Fri Apr 18 16:27:49 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 12:27:49 -0400 Subject: [et-mgmt-tools] Re: Cobbler, findks.cgi, registration, and so forth In-Reply-To: <4808CAC4.9020908@redhat.com> References: <4808CAC4.9020908@redhat.com> Message-ID: <4808CC05.3000009@redhat.com> Michael DeHaan wrote: > > Hi folks, > > So earlier I wrote about some ideas around automatically registering > systems when Cobbler sees them, and I wrote up some example scripts > for usage by the FreeLinuxPC guys. To me, this seems pretty > compelling as you wouldn't have to manually build up a list of every > MAC address in your data center and so on. > It turns out some of the mac data I was relying on isn't present, so > this didn't work as well as I thought it did -- but -- good news -- I > can fix it. > > So since I need to fix this, and wanted to bounce some ideas off > everyone and find out if this would be useful or not. It seems useful > to me anyway, at least as a configuration option. > > The idea -- all kickstart requests through cobbler will now go through > a cgi (or more likely, a new mod python piece for performance reasons) > that will serve up the kickstart file for all cobbler-hosted kickstart > files. Then, we have the configuration ability to automatically add > new system objects (correctly configured to the proper profile) when > they get installed. Since we are also doing this via a web script, > we can also decide to re-evaluate the templates at runtime, > effectively eliminating the need for "cobbler sync" for anything but > regenerating DNS/DHCP. > > For an example of the registration case -- if you tftpboot 500 new > systems ("straight off the truck"), and you use the PXE menu to assign > some to "webservers" and some to "dbservers", this reorganization of > how we do things would allow us to auto-create system records, > correctly assigned to the profile they were assigned to, with the MAC > data already filled in. > > For security reasons, this would only add new system records if the > objects were not already there. Due to various catch-22's, if you > add a new system this way, and then reinstall it using the PXE menus, > we can't have it update the profile associations in cobbler. However > -- you wouldn't need to do this, because you could do something as > simple as: > > cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1 > (and cycle power) > > in order to do reinstalls. > > This seems to be a nice solution for logging the profiles and mac info > at first install time and saves some data entry. (and yes, we'll have > a setting to turn this off). > > Thoughts on this and on install time template evaluation? > > --Michael > Minor clarification -- if anyone is familiar with findks.cgi, this is somewhat different. This would be more like "http://$server/cobbler/getks?profile=foo", though Anaconda takes care of feeding the mac (and the IP) info to the script/program. We would want to log the mac, but I'm unsure if we want to store the IP... as that would instantly turn a regular DHCP ip into a DHCP reservation if using the mangage_dhcp feature. I kind of like that idea though, but wanted to bounce that off people who were using Cobbler to manage DHCP -- as that may not fit workflows. In terms of settings, it looks like we're going to have auto_register_new_systems y/n (and possibly) auto_register_ip_info y/n (We could possibly also expand koan to use more of this data to help prevent virtual MAC collisions when installing with --profile records and not --system records, provided we make a remote XMLRPC call to retrieve a free MAC address) From dlutter at redhat.com Fri Apr 18 17:17:44 2008 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 18 Apr 2008 17:17:44 +0000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208484135.7867.173.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> Message-ID: <1208539064.3610.82.camel@localhost.localdomain> On Fri, 2008-04-18 at 12:02 +1000, Mike MacCana wrote: > * create an editor for that format (which handles data - settings, > values, parents and children, rather than presentation related info > like lines and paragraph) At its heart, Augeas is a tool to make writing such editors easy, easier than starting from scratch for every format. Of course, there's also benefit for users if they can edit many config files with the same tool instead of having a separate tool for each config file. > Using 'widely varying formats' is not 'valuable'. I was a little oblique .. I meant 'that config data is stored in text files is valuable', mostly to contrast that with some other approaches that have been proposed in the past. > It's an unfortunate accident that wastes everyone's time with various > horrible bandaid solutions I think we're all in agreement that the situation is far from the best imaginable. That's why I chose "Augeas"[1] as the name for this ;) David [1] http://en.wikipedia.org/wiki/Augeas "In Greek mythology, Augeas ... was King of Elis ... He is best known for his stables, which housed the single greatest number of cattle in the country and had never been cleaned" From dlutter at redhat.com Fri Apr 18 17:22:04 2008 From: dlutter at redhat.com (David Lutterkort) Date: Fri, 18 Apr 2008 17:22:04 +0000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <20080418140143.GC28962@redhat.com> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> <1208489946.7867.178.camel@mmaccana-laptop> <20080418140143.GC28962@redhat.com> Message-ID: <1208539324.3610.87.camel@localhost.localdomain> On Fri, 2008-04-18 at 15:01 +0100, Daniel P. Berrange wrote: > Even if you convince upstream to adopt your grand unified configuration scheme And therein lies the rub. I've been very careful to make sure that Augeas' usability does not depend on any upstream adopting it - they have perfectly valid reasons not to do that, starting with that they can't tell which proposed scheme will actually work out (and therefore deserve their support) Augeas (or any similar config scheme) _has_ to be workable without upstream support - it would be great if we get some eventually [1], but we first need to prove that Augeas is worth their effort. David [1] And for now, it would really only require them shipping a schema with their software, i.e. plonking one text file into /usr/share/augeas/lenses From mdehaan at redhat.com Fri Apr 18 19:05:19 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 15:05:19 -0400 Subject: [et-mgmt-tools] cobbler reposync with different arch In-Reply-To: <62E8616DA7F577429A29CFD86648DA3C1F3F47@mail02.internal.rmplc.net> References: <62E8616DA7F577429A29CFD86648DA3C1F3F47@mail02.internal.rmplc.net> Message-ID: <4808F0EF.1060402@redhat.com> Adam Goodall wrote: > > All > > I?m having trouble getting cobbler to sync packages for an arch that > is different to the cobbler servers own. I have cobbler running on an > i386 box and for one of the repos I?m mirroring I want to pull down > x86_64. However when the repository syncs down it will only pull the > noarch RPM?s and completely ignores the x86_64 ones. I have the > correct arch set for the repo as is shown in the output of cobbler > repo report: > I missed this in the queue earlier. The arch parameter is needed for reposync (part of yum, not to be confused with the cobbler reposync which knows about both yum and rsync) to pull down files of a different arch. I would file a bug with yumdownloader (see the /usr/bin/yumdownloader) command below if you think it's not pulling down the right packages. > repo : dag-EL4-x86_64 > > mirror : http://apt.sw.be/redhat/el4/en/x86_64/rpmforge/ > > keep updated : True > > priority : 99 > > rpm list : ['nagios-plugins', 'nagios-nrpe', 'zonecheck'] > > createrepo_flags : -c cache > > arch : x86_64 > > yum options : {} > > In this example the zonecheck rpm (which is noarch) is pulled but the > two nagios rpm?s are ignored.: > > # cobbler reposync --only=dag-EL4-x86_64 > > - creating: /var/www/cobbler/repo_mirror/.origin/dag-EL4-x86_64.repo > > - /usr/bin/yumdownloader --resolve -c > /var/www/cobbler/repo_mirror/.origin/dag-EL4-x86_64.repo > --destdir=/var/www/cobbler/repo_mirror/dag-EL4-x86_64 nagios-plugins > nagios-nrpe zonecheck > > No Match for argument nagios-plugins > > No Match for argument nagios-nrpe > > /var/www/cobbler/repo_mirror/dag-EL4-x86_64/zonecheck-2.0.4-1.2.el4.rf.noarch.rpm > already exists and appears to be complete > > - createrepo -c cache /var/www/cobbler/repo_mirror/dag-EL4-x86_64 > > 1/1 - zonecheck-2.0.4-1.2.el4.rf.noarch.rpm > > Saving Primary metadata > > Saving file lists metadata > > Saving other metadata > > - creating: /var/www/cobbler/repo_mirror/dag-EL4-x86_64/config.repo > > Does anyone have any ideas where im going wrong or what I need to do > to make it work? If it helps I?m running on RHEL5 with the following > versions: > > # rpm -qa| egrep -i "cobbler|yum" > > yum-utils-1.0.4-3.el5 > > yum-updatesd-3.0.1-5.el5 > > yum-rhn-plugin-0.5.2-5.el5_1.2 > > yum-3.0.1-5.el5 > > yum-security-1.0.4-3.el5 > > cobbler-0.8.2-1.el5 > > yum-metadata-parser-1.0-8.fc6 > > Thanks > > Adam > > _________________________________________________________________________ > > You might be interested in this... > > Find out what funding is available for schools in England over the > next three years: > http://www.rm.com/funding > > _________________________________________________________________________ > > P.S. Think Green - don't print this email unless you really need to. > > This message is confidential, so please treat it appropriately and for > its intended purpose only. In particular, if it refers to any > technical data, terms or prices not generally available or known, such > items are "commercially sensitive information" within the terms of the > Freedom of Information Act 2000 and related laws. As it would be > prejudicial to RM's commercial interests if these were disclosed, > please refrain from doing so. > > As Internet communications are not secure, please be aware that RM > cannot accept responsibility for its contents. Any views or opinions > presented are those of the author only and not of RM. If you are not > the intended recipient of this e-mail, please accept our apologies and > arrange for copies of it to be deleted. For your information, RM may > intercept incoming and outgoing email communications. > > RM Education plc > Registered Office: New Mill House, 183 Milton Park, Abingdon, > Oxfordshire, OX14 4SE, England > Registered Number: 1148594 > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From smooge at gmail.com Fri Apr 18 19:27:12 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Fri, 18 Apr 2008 13:27:12 -0600 Subject: [et-mgmt-tools] RFC Cobbler Purge command Message-ID: <80d7e4090804181227w258d471eoadd1b4287f00ea61@mail.gmail.com> This is probably overkill, but as I am trying to install various 'channels' from DVD's I realized that I wanted to remove some DVD's later and trying to track all the data down connected to it wasn't something immediately known. cobbler purge --name= [--force] Would be a way to 'wipe' out data from a system if it is no longer needed (system may be overkill) but would allow for you to something like cobbler purge distro --name=rhel-4.6-as-xen-i386 WARNING: profile UNM-rhel4-xen-base is linked to distro rhel-4.6-as-xen-i386 WARNING: system xxx_unm_edu is linked to UNM-rhel4-xen-base WARNING: system prn_unm_edu is linked to UNM-rhel4-xen-base The user could then move those to other profiles (somehow). And if a --force is done then they all are removed from the system removing all the rpm directories in /var/www/cobbler etc connected to that profile. -- 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 wright at imageworks.com Fri Apr 18 19:32:07 2008 From: wright at imageworks.com (Peter Wright) Date: Fri, 18 Apr 2008 12:32:07 -0700 Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: <4808CAC4.9020908@redhat.com> References: <4808CAC4.9020908@redhat.com> Message-ID: <4808F737.5040102@imageworks.com> Michael DeHaan wrote: > > Hi folks, > > > The idea -- all kickstart requests through cobbler will now go through > a cgi (or more likely, a new mod python piece for performance reasons) > that will serve up the kickstart file for all cobbler-hosted kickstart > files. Then, we have the configuration ability to automatically add > new system objects (correctly configured to the proper profile) when > they get installed. Since we are also doing this via a web script, > we can also decide to re-evaluate the templates at runtime, > effectively eliminating the need for "cobbler sync" for anything but > regenerating DNS/DHCP. > > For an example of the registration case -- if you tftpboot 500 new > systems ("straight off the truck"), and you use the PXE menu to assign > some to "webservers" and some to "dbservers", this reorganization of > how we do things would allow us to auto-create system records, > correctly assigned to the profile they were assigned to, with the MAC > data already filled in. > this would be very helpful indeed. although i suspect having to manually select your install via a menu can get painful when lighting up a bunch of blade systems - if i read this correctly. we've been kicking around the idea of polling MAC addresses from our edge switches then having some glue code enter those addy's into cobbler and assign them a specific profile (we usually find ourselves putting all of our render nodes for example on their own edge switch so we don't have to worry about mixed use profiles in the use case). don't get me wrong though - auto-reg would be huge :) -p -- Peter Wright Systems Engineer Sony Pictures Imageworks wright at imageworks.com www.imageworks.com From mdehaan at redhat.com Fri Apr 18 20:30:11 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 16:30:11 -0400 Subject: [et-mgmt-tools] RFC Cobbler Purge command In-Reply-To: <80d7e4090804181227w258d471eoadd1b4287f00ea61@mail.gmail.com> References: <80d7e4090804181227w258d471eoadd1b4287f00ea61@mail.gmail.com> Message-ID: <480904D3.60105@redhat.com> Stephen John Smoogen wrote: > This is probably overkill, but as I am trying to install various > 'channels' from DVD's I realized that I wanted to remove some DVD's > later and trying to track all the data down connected to it wasn't > something immediately known. > > cobbler purge --name= [--force] > > Would be a way to 'wipe' out data from a system if it is no longer > needed (system may be overkill) but would allow for you to something > like > > cobbler purge distro --name=rhel-4.6-as-xen-i386 > > WARNING: profile UNM-rhel4-xen-base is linked to distro rhel-4.6-as-xen-i386 > WARNING: system xxx_unm_edu is linked to UNM-rhel4-xen-base > WARNING: system prn_unm_edu is linked to UNM-rhel4-xen-base > > The user could then move those to other profiles (somehow). And if a > --force is done then they all are removed from the system removing all > the rpm directories in /var/www/cobbler etc connected to that profile. > > > I agree. There are a couple of things available already for this in 0.8.X that get you halfway: cobbler distro delete --name=foo will warn (but doesn't give the full linkage report of everything affected...it most definitely should). cobbler distro delete --name=foo --recursive will delete child objects (it's a valid command on profiles also) There's also a ticket open for a --delete-files option, which would do the rest. (This would involve finding things that were obviously mirrored by cobbler and clearing them out.) Support for deletion and assigning objects to other objects could be interesting as well, but can be done with an edit before running the delete in that case. If we added a command like "cobbler system whatuses --profile=X" we could possibly do all sorts of clever things with xargs. That may be crazy though :) --Michael From jim at rossberry.com Fri Apr 18 20:37:27 2008 From: jim at rossberry.com (Jim Wildman) Date: Fri, 18 Apr 2008 16:37:27 -0400 (EDT) Subject: [et-mgmt-tools] RFC Cobbler Purge command In-Reply-To: <480904D3.60105@redhat.com> References: <80d7e4090804181227w258d471eoadd1b4287f00ea61@mail.gmail.com> <480904D3.60105@redhat.com> Message-ID: On Fri, 18 Apr 2008, Michael DeHaan wrote: > If we added a command like "cobbler system whatuses --profile=X" we could > possibly do all sorts of clever things with xargs. That may be crazy though > :) > > --Michael > That one strikes me as very useful. ie, if I change this object, where do the ripples go?? ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com "Society in every state is a blessing, but Government, even in its best state, is a necessary evil; in its worst state, an intolerable one." Thomas Paine From mdehaan at redhat.com Fri Apr 18 22:53:10 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 18:53:10 -0400 Subject: [et-mgmt-tools] Re: Cobbler, findks.cgi, registration, and so forth In-Reply-To: <4808CC05.3000009@redhat.com> References: <4808CAC4.9020908@redhat.com> <4808CC05.3000009@redhat.com> Message-ID: <48092656.5070904@redhat.com> Michael DeHaan wrote: > Michael DeHaan wrote: >> >> Hi folks, >> >> So earlier I wrote about some ideas around automatically registering >> systems when Cobbler sees them, and I wrote up some example scripts >> for usage by the FreeLinuxPC guys. To me, this seems pretty >> compelling as you wouldn't have to manually build up a list of every >> MAC address in your data center and so on. >> It turns out some of the mac data I was relying on isn't present, so >> this didn't work as well as I thought it did -- but -- good news -- I >> can fix it. >> >> So since I need to fix this, and wanted to bounce some ideas off >> everyone and find out if this would be useful or not. It seems >> useful to me anyway, at least as a configuration option. >> >> The idea -- all kickstart requests through cobbler will now go >> through a cgi (or more likely, a new mod python piece for performance >> reasons) that will serve up the kickstart file for all cobbler-hosted >> kickstart files. Then, we have the configuration ability to >> automatically add new system objects (correctly configured to the >> proper profile) when they get installed. Since we are also doing >> this via a web script, we can also decide to re-evaluate the >> templates at runtime, effectively eliminating the need for "cobbler >> sync" for anything but regenerating DNS/DHCP. >> >> For an example of the registration case -- if you tftpboot 500 new >> systems ("straight off the truck"), and you use the PXE menu to >> assign some to "webservers" and some to "dbservers", this >> reorganization of how we do things would allow us to auto-create >> system records, correctly assigned to the profile they were assigned >> to, with the MAC data already filled in. >> >> For security reasons, this would only add new system records if the >> objects were not already there. Due to various catch-22's, if you >> add a new system this way, and then reinstall it using the PXE menus, >> we can't have it update the profile associations in cobbler. However >> -- you wouldn't need to do this, because you could do something as >> simple as: >> >> cobbler system edit --name=foo --newprofile=bar --netboot-enabled=1 >> (and cycle power) >> >> in order to do reinstalls. >> >> This seems to be a nice solution for logging the profiles and mac >> info at first install time and saves some data entry. (and yes, >> we'll have a setting to turn this off). >> >> Thoughts on this and on install time template evaluation? >> >> --Michael >> > > Minor clarification -- if anyone is familiar with findks.cgi, this is > somewhat different. This would be more like > "http://$server/cobbler/getks?profile=foo", though Anaconda takes care > of feeding the mac (and the IP) info to the script/program. We > would want to log the mac, but I'm unsure if we want to store the > IP... as that would instantly turn a regular DHCP ip into a DHCP > reservation if using the mangage_dhcp feature. I kind of like that > idea though, but wanted to bounce that off people who were using > Cobbler to manage DHCP -- as that may not fit workflows. > > In terms of settings, it looks like we're going to have > > auto_register_new_systems y/n > (and possibly) auto_register_ip_info y/n > > (We could possibly also expand koan to use more of this data to help > prevent virtual MAC collisions when installing with --profile records > and not --system records, provided we make a remote XMLRPC call to > retrieve a free MAC address) > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools A good bit of this is checked in now -- registration will just use the mac and happens when a system requests a kickstart and also has kssendmac set. There will be a setting to enable this behavior (off by default). I've been able to clean up the sync code /considerably/ by removing a lot of legacy filesystem stuff from previous Cobbler versions. The code for DHCP, yum, and PXE templating is now split out into different files and so forth. All CGIs have been moved to mod_python as well and use the XMLRPC API directly. I will be testing/refining all of this next week -- and it looks like we can get the 0.9 test release out much sooner than I expected given the roadmap: https://fedorahosted.org/cobbler/wiki/TheRoadmap Another nice thing about this cleanup is it is making sync, as well as individual system edits, a good deal speedier too. --Michael From mdehaan at redhat.com Fri Apr 18 22:55:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 18:55:33 -0400 Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: <4808F737.5040102@imageworks.com> References: <4808CAC4.9020908@redhat.com> <4808F737.5040102@imageworks.com> Message-ID: <480926E5.1050006@redhat.com> >> > this would be very helpful indeed. > although i suspect having to manually select your install via a menu > can get painful when lighting up a bunch of blade systems - if i read > this correctly. > we've been kicking around the idea of polling MAC addresses from our > edge switches then having some glue code enter those addy's into > cobbler and assign them a specific profile (we usually find ourselves > putting all of our render nodes for example on their own edge switch > so we don't have to worry about mixed use profiles in the use case). > > don't get me wrong though - auto-reg would be huge :) > Good deal! I think you might know about this, but you can also do the following trick today that makes life a lot easier than using menus: cobbler system add --name=default --profile=foo # power up 500 systems cobbler system add --name=default --profile=bar # power up another 500 Coupled with auto-registration that could be pretty slick :) > -p > From mdehaan at redhat.com Fri Apr 18 22:56:46 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 18 Apr 2008 18:56:46 -0400 Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: <480926E5.1050006@redhat.com> References: <4808CAC4.9020908@redhat.com> <4808F737.5040102@imageworks.com> <480926E5.1050006@redhat.com> Message-ID: <4809272E.7040400@redhat.com> Michael DeHaan wrote: > >>> >> this would be very helpful indeed. >> although i suspect having to manually select your install via a menu >> can get painful when lighting up a bunch of blade systems - if i read >> this correctly. >> we've been kicking around the idea of polling MAC addresses from our >> edge switches then having some glue code enter those addy's into >> cobbler and assign them a specific profile (we usually find ourselves >> putting all of our render nodes for example on their own edge switch >> so we don't have to worry about mixed use profiles in the use case). >> >> don't get me wrong though - auto-reg would be huge :) >> > > Good deal! > > I think you might know about this, but you can also do the following > trick today that makes life a lot easier than using menus: > > cobbler system add --name=default --profile=foo > # power up 500 systems > cobbler system add --name=default --profile=bar > # power up another 500 > > Coupled with auto-registration that could be pretty slick :) > >> -p >> > > That of course should end with: cobbler system remove --name=default Otherwise, it would be rather suprising. When you have the "default" system record engaged the menus do not fire up. --Michael From clalance at redhat.com Sat Apr 19 01:18:35 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 18 Apr 2008 21:18:35 -0400 Subject: [et-mgmt-tools] [PATCH]: Make virt-viewer ungrab the mouse and keyboard on un-focus Message-ID: <4809486B.2070600@redhat.com> All, I ran into an unfortunate situation today with virt-viewer. I was working inside a virt-viewer window with the mouse and keyboard grabbed. In the meantime, a long running job that I had started earlier finished up, and fired up another virt-viewer window (to a different guest). Unfortunately, however, my window manager decided to place that new virt-viewer window on top of the one I was currently working in. Once that happened, I couldn't give input to either window, so I couldn't ungrab the old window or kill the new window. The attached patch prevents this situation by doing a forced ungrab when we get a focus-out-event from GTK. Signed-off-by: Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: virt-viewer-focus-out.patch Type: text/x-patch Size: 1051 bytes Desc: not available URL: From msf at kisoku.net Sat Apr 19 04:39:21 2008 From: msf at kisoku.net (Mathieu Sauve-Frankel) Date: Sat, 19 Apr 2008 13:39:21 +0900 Subject: [et-mgmt-tools] cobbler reposync proxy issues Message-ID: <20080419043921.GA17236@shingen.kisoku.net> Hi, I'm currently using cobbler 0.8.2 from EPEL on RHEL5-x86_64. It seems cobbler reposync does not respect proxy entries in /etc/yum.conf. Is this expected ? I've temporarily worked around this by adding a file that sets the http_proxy and ftp_proxy environment variables system-wide in /etc/profile.d/ -- Mathieu Sauve-Frankel From Pablo.Iranzo at redhat.com Sat Apr 19 17:51:52 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 19:51:52 +0200 (CEST) Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) Message-ID: Hi Attached are a patch for cobbler missing the config entry to submited isc_set_host_name with default to 0. The patch for Koan is for being used with newer versions of cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the kickstart which koan uses, is "hard-coded". I think that the behaviour should be cobbler to provided the URL for the kickstart, removing dependencies between cobbler and koan, or at least, provide version number from cobbler to koan "client", for koan to construct URL's for kickstart, kernel, etc appropiately. ?omments? Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? -------------- next part -------------- A non-text attachment was scrubbed... Name: koan.cobbler0.9x.diff Type: text/x-diff Size: 658 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cobbler-config.missing.isc_host_name.diff Type: text/x-diff Size: 348 bytes Desc: URL: From Pablo.Iranzo at redhat.com Sat Apr 19 17:58:21 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 19:58:21 +0200 (CEST) Subject: [et-mgmt-tools] Re: Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: Regarding this upgrade... Koan can now replace boot entry for reprovision a system but during the upgrade from cobbler 0.8 to 0.9, I found another problem: Cobbler repos are not longer valid... so any single system which was kickstarted with cobber and keeps the repos provided by it, should be "tweaked". As a profile (associated to a system) can be updated from time to time... ?what do you think about "koan --upgrade-repos" That will update system repos to the ones associated with current profile, or for safety, to installation profile repos, but based on new cobbler provide information, overwriting actual ones for the good ones. Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Sat, 19 Apr 2008, Pablo Iranzo G?mez wrote: > > Hi > Attached are a patch for cobbler missing the config entry to > submited isc_set_host_name with default to 0. > > The patch for Koan is for being used with newer versions of > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > kickstart which koan uses, is "hard-coded". > > I think that the behaviour should be cobbler to provided the URL > for the kickstart, removing dependencies between cobbler and koan, or at > least, provide version number from cobbler to koan "client", for koan to > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > Regards > Pablo > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? From Pablo.Iranzo at redhat.com Sat Apr 19 18:30:58 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 20:30:58 +0200 (CEST) Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: <4809272E.7040400@redhat.com> References: <4808CAC4.9020908@redhat.com> <4808F737.5040102@imageworks.com> <480926E5.1050006@redhat.com> <4809272E.7040400@redhat.com> Message-ID: Hi This auto-registration feature seems not to work if using koan to replace a machine, as it relies on MAC and: koan -r downloads the file using wget to store it, so no mac info sent, machine would be correctly deployed, but no ks request will be made by anaconda, so no autoregistration. wget in kickstart profile, also, doesn't send mac, so this will not register the machine. Solution: ?Make Koan to always use http://cobblerserver as the ks path instead of downloading to disk? Regards Pablo PD: I like this idea of auto-registration -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Fri, 18 Apr 2008, Michael DeHaan wrote: > Michael DeHaan wrote: > > > >>> > >> this would be very helpful indeed. > >> although i suspect having to manually select your install via a menu > >> can get painful when lighting up a bunch of blade systems - if i read > >> this correctly. > >> we've been kicking around the idea of polling MAC addresses from our > >> edge switches then having some glue code enter those addy's into > >> cobbler and assign them a specific profile (we usually find ourselves > >> putting all of our render nodes for example on their own edge switch > >> so we don't have to worry about mixed use profiles in the use case). > >> > >> don't get me wrong though - auto-reg would be huge :) > >> > > > > Good deal! > > > > I think you might know about this, but you can also do the following > > trick today that makes life a lot easier than using menus: > > > > cobbler system add --name=default --profile=foo > > # power up 500 systems > > cobbler system add --name=default --profile=bar > > # power up another 500 > > > > Coupled with auto-registration that could be pretty slick :) > > > >> -p > >> > > > > > > That of course should end with: > > cobbler system remove --name=default > > Otherwise, it would be rather suprising. When you have the "default" > system record engaged the menus do not fire up. > > --Michael > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From Pablo.Iranzo at redhat.com Sat Apr 19 18:57:13 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 20:57:13 +0200 (CEST) Subject: [et-mgmt-tools] Patch to reenable memtest entry creation on Cobbler 0.9 Message-ID: Hi This should be applied to fix the memtest entry creation on cobbler 0.9x after moving memtest to images/ Regards Pablo diff --git a/cobbler/pxegen.py b/cobbler/pxegen.py index 527b6a2..e39fdc8 100644 --- a/cobbler/pxegen.py +++ b/cobbler/pxegen.py @@ -186,7 +186,7 @@ class PXEGen: memtests = glob.glob(self.bootloc + "/images/memtest*") if len(memtests) > 0: pxe_menu_items = pxe_menu_items + "\n\n" - for memtest in glob.glob(self.bootloc + '/memtest*'): + for memtest in glob.glob(self.bootloc + '/images/memtest*'): base = os.path.basename(memtest) contents = self.write_memtest_pxe("/images/%s" % base) pxe_menu_items = pxe_menu_items + contents + "\n" -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? From Pablo.Iranzo at redhat.com Sat Apr 19 20:39:49 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 22:39:49 +0200 (CEST) Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: References: <4808CAC4.9020908@redhat.com> <4808F737.5040102@imageworks.com> <480926E5.1050006@redhat.com> <4809272E.7040400@redhat.com> Message-ID: Just a question, I've seen (using PHP) that the kssendmac, provides a parameter named "X-RHN-PROVISIONING-MAC-0" with "-" instead of "_" is this ok for the code in services.py? (scripts/services.py shows "HTTP_X_RHN_PROVISIONING_MAC_0") Also found that it requires profile to be defined, but I haven't found the code for that in the apache handler. But, for now, I can't make it to autoregister :) Regards! Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Sat, 19 Apr 2008, Pablo Iranzo G?mez wrote: > Hi > This auto-registration feature seems not to work if using koan to > replace a machine, as it relies on MAC and: > > koan -r downloads the file using wget to store it, so no mac info > sent, machine would be correctly deployed, but no ks request will be made > by anaconda, so no autoregistration. > > wget in kickstart profile, also, doesn't send mac, so this will > not register the machine. > > Solution: > > ?Make Koan to always use http://cobblerserver as the ks path > instead of downloading to disk? > > Regards > Pablo > > PD: I like this idea of auto-registration > > > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? > > On Fri, 18 Apr 2008, Michael DeHaan wrote: > > > Michael DeHaan wrote: > > > > > >>> > > >> this would be very helpful indeed. > > >> although i suspect having to manually select your install via a menu > > >> can get painful when lighting up a bunch of blade systems - if i read > > >> this correctly. > > >> we've been kicking around the idea of polling MAC addresses from our > > >> edge switches then having some glue code enter those addy's into > > >> cobbler and assign them a specific profile (we usually find ourselves > > >> putting all of our render nodes for example on their own edge switch > > >> so we don't have to worry about mixed use profiles in the use case). > > >> > > >> don't get me wrong though - auto-reg would be huge :) > > >> > > > > > > Good deal! > > > > > > I think you might know about this, but you can also do the following > > > trick today that makes life a lot easier than using menus: > > > > > > cobbler system add --name=default --profile=foo > > > # power up 500 systems > > > cobbler system add --name=default --profile=bar > > > # power up another 500 > > > > > > Coupled with auto-registration that could be pretty slick :) > > > > > >> -p > > >> > > > > > > > > > > That of course should end with: > > > > cobbler system remove --name=default > > > > Otherwise, it would be rather suprising. When you have the "default" > > system record engaged the menus do not fire up. > > > > --Michael > > > > > > _______________________________________________ > > 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 > From Pablo.Iranzo at redhat.com Sat Apr 19 20:55:25 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sat, 19 Apr 2008 22:55:25 +0200 (CEST) Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: Hi I've seen that Koan puts kickstart inside the initrd.img and references it as file:ks.cfg, but I don't know the reason for this. In order to enable auto-registration (based on pxelinux.cfg/defaults entries), the ks should we changed by this diff on koan/app.py: -------------------------------------------------------------------- @@ -782,7 +779,7 @@ class Koan: if not os.path.exists("/sbin/grubby"): raise InfoException, "grubby is not installed" k_args = self.safe_load(profile_data,'kernel_options',default='') - k_args = k_args + " ks=file:ks.cfg" + k_args = k_args + " ks=" + profile_data["kickstart"] kickstart = self.safe_load(profile_data,'kickstart') -------------------------------------------------------------------- So the ks= would be constructed with the cobbler-provided ks Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Sat, 19 Apr 2008, Pablo Iranzo G?mez wrote: > > Hi > Attached are a patch for cobbler missing the config entry to > submited isc_set_host_name with default to 0. > > The patch for Koan is for being used with newer versions of > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > kickstart which koan uses, is "hard-coded". > > I think that the behaviour should be cobbler to provided the URL > for the kickstart, removing dependencies between cobbler and koan, or at > least, provide version number from cobbler to koan "client", for koan to > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > Regards > Pablo > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? From Pablo.Iranzo at redhat.com Sat Apr 19 22:36:40 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sun, 20 Apr 2008 00:36:40 +0200 (CEST) Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: After aplying this patch: (previous mail + extended for koan -r): -------------------- diff --git a/koan/app.py b/koan/app.py index dba6c65..b5837c5 100755 --- a/koan/app.py +++ b/koan/app.py @@ -534,13 +534,10 @@ class Koan: # initialise the profile, from the server if any if self.profile: profile_data = self.get_profile_xmlrpc(self.profile) - filler = "kickstarts" elif self.system: profile_data = self.get_system_xmlrpc(self.system) - filler = "kickstarts_sys" else: profile_data = {} - filler = None if self.no_cobbler: # if the value given to no_cobbler has no url protocol @@ -563,8 +560,8 @@ class Koan: if profile_data.has_key("kickstart"): # fix URLs - if filler and profile_data["kickstart"].startswith("/"): - profile_data["kickstart"] = "http://%s/cblr/%s/%s/ks.cfg" % (profile_data['server'], filler, profile_data['name']) + if profile_data["kickstart"].startswith("/"): + profile_data["kickstart"] = "http://%s/cblr/svc/?op=ks&profile=%s" % (profile_data['server'], profile_data['profile']) # find_kickstart source tree in the kickstart file self.get_install_tree_from_kickstart(profile_data) @@ -782,7 +779,7 @@ class Koan: if not os.path.exists("/sbin/grubby"): raise InfoException, "grubby is not installed" k_args = self.safe_load(profile_data,'kernel_options',default='') - k_args = k_args + " ks=file:ks.cfg" + k_args = k_args + " ks=" + profile_data["kickstart"] kickstart = self.safe_load(profile_data,'kickstart') ---------------------------- I'm getting: # koan -s 172.26.0.254 -V Xen -v --profile=wks-CentOS 'profile' Any hint on what I did wrong? Thanks Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Sat, 19 Apr 2008, Pablo Iranzo G?mez wrote: > > Hi > Attached are a patch for cobbler missing the config entry to > submited isc_set_host_name with default to 0. > > The patch for Koan is for being used with newer versions of > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > kickstart which koan uses, is "hard-coded". > > I think that the behaviour should be cobbler to provided the URL > for the kickstart, removing dependencies between cobbler and koan, or at > least, provide version number from cobbler to koan "client", for koan to > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > Regards > Pablo > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? From Pablo.Iranzo at redhat.com Sat Apr 19 22:46:21 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Sun, 20 Apr 2008 00:46:21 +0200 (CEST) Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: Forgot, this just happens if specifying --profile on command line. If doing specifying "system" I got: libvir: XML error : line 10: EntityRef: expecting ';' libvir: Xen Daemon error : XML description for domain is not well formed or invalid virDomainCreateLinux() failed XML description for domain is not well formed or invalid Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Sun, 20 Apr 2008, Pablo Iranzo G?mez wrote: > After aplying this patch: (previous mail + extended for koan -r): > -------------------- > diff --git a/koan/app.py b/koan/app.py > index dba6c65..b5837c5 100755 > --- a/koan/app.py > +++ b/koan/app.py > @@ -534,13 +534,10 @@ class Koan: > # initialise the profile, from the server if any > if self.profile: > profile_data = self.get_profile_xmlrpc(self.profile) > - filler = "kickstarts" > elif self.system: > profile_data = self.get_system_xmlrpc(self.system) > - filler = "kickstarts_sys" > else: > profile_data = {} > - filler = None > > if self.no_cobbler: > # if the value given to no_cobbler has no url protocol > @@ -563,8 +560,8 @@ class Koan: > if profile_data.has_key("kickstart"): > > # fix URLs > - if filler and profile_data["kickstart"].startswith("/"): > - profile_data["kickstart"] = "http://%s/cblr/%s/%s/ks.cfg" > % (profile_data['server'], filler, profile_data['name']) > + if profile_data["kickstart"].startswith("/"): > + profile_data["kickstart"] = > "http://%s/cblr/svc/?op=ks&profile=%s" % (profile_data['server'], > profile_data['profile']) > > # find_kickstart source tree in the kickstart file > self.get_install_tree_from_kickstart(profile_data) > @@ -782,7 +779,7 @@ class Koan: > if not os.path.exists("/sbin/grubby"): > raise InfoException, "grubby is not installed" > k_args = > self.safe_load(profile_data,'kernel_options',default='') > - k_args = k_args + " ks=file:ks.cfg" > + k_args = k_args + " ks=" + profile_data["kickstart"] > > kickstart = self.safe_load(profile_data,'kickstart') > ---------------------------- > > > > I'm getting: > > > # koan -s 172.26.0.254 -V Xen -v --profile=wks-CentOS > 'profile' > > Any hint on what I did wrong? > > Thanks > Pablo > > > > > -- > Pablo Iranzo G?mez > (http://Alufis35.uv.es/~iranzo/) > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > -- > Postulado de Boling sobre la Ley de Murphy: > > Si se encuentra bien, no se preocupe. Se le pasar? > > On Sat, 19 Apr 2008, Pablo Iranzo G?mez wrote: > > > > > Hi > > Attached are a patch for cobbler missing the config entry to > > submited isc_set_host_name with default to 0. > > > > The patch for Koan is for being used with newer versions of > > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > > kickstart which koan uses, is "hard-coded". > > > > I think that the behaviour should be cobbler to provided the URL > > for the kickstart, removing dependencies between cobbler and koan, or at > > least, provide version number from cobbler to koan "client", for koan to > > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > > > Regards > > Pablo > > > > > > > > -- > > Pablo Iranzo G?mez > > (http://Alufis35.uv.es/~iranzo/) > > (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) > > -- > > Postulado de Boling sobre la Ley de Murphy: > > > > Si se encuentra bien, no se preocupe. Se le pasar? > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From rjones at redhat.com Sun Apr 20 09:04:03 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 20 Apr 2008 10:04:03 +0100 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208484135.7867.173.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> Message-ID: <20080420090403.GA4482@amd.home.annexia.org> On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote: > Using 'widely varying formats' is not 'valuable'. It's an unfortunate > accident that wastes everyone's time with various horrible bandaid > solutions, and occasionally makes destroying user data an 'accepted > limitation' of tools like system-config-named. Different formats suit different uses, and in any case I wouldn't trust the people who would develop this new "super-format" not to do something stupid like using XML. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jason at rampaginggeek.com Sun Apr 20 13:31:11 2008 From: jason at rampaginggeek.com (Jason Edgecombe) Date: Sun, 20 Apr 2008 09:31:11 -0400 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <20080420090403.GA4482@amd.home.annexia.org> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <20080420090403.GA4482@amd.home.annexia.org> Message-ID: <480B459F.4000208@rampaginggeek.com> Richard W.M. Jones wrote: > On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote: > >> Using 'widely varying formats' is not 'valuable'. It's an unfortunate >> accident that wastes everyone's time with various horrible bandaid >> solutions, and occasionally makes destroying user data an 'accepted >> limitation' of tools like system-config-named. >> > > Different formats suit different uses, and in any case I wouldn't > trust the people who would develop this new "super-format" not to do > something stupid like using XML. > > Rich. > > This sounds a lot like what gconfd was made for. How is it different? Jason From dlutter at redhat.com Sun Apr 20 18:58:21 2008 From: dlutter at redhat.com (David Lutterkort) Date: Sun, 20 Apr 2008 11:58:21 -0700 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <480B459F.4000208@rampaginggeek.com> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <20080420090403.GA4482@amd.home.annexia.org> <480B459F.4000208@rampaginggeek.com> Message-ID: <1208717901.3610.142.camel@localhost.localdomain> On Sun, 2008-04-20 at 09:31 -0400, Jason Edgecombe wrote: > This sounds a lot like what gconfd was made for. How is it different? gconfd addresses slightly different uses in a different environment: its main focus is on dektop apps, and because of its origin and focus on the Gnome desktop, it's reasonable to expect applications to be built to gconf's API and use it as a 'master' data storage. Augeas is more focused on all the files that are _not_ managed/manageable by gconfd, especially all the sundry config files in /etc; there it's unreasonable that the programs using those config files will adapt to some grand unified API and storage scheme. It is also unrealistic, as attempts at introducing that have failed --- and uptream has good reasons for not jumping at such a cheme: for one, it's not clear if any of those schemes will find wide enough acceptance to make supporting it worthwhile. The way a daemon processes config files to get its config out if it is also different from how an editing tool like Augeas has to process it: the daemon can just ignore comments, space etc. and does never have to worry about writing the file. These are two very important concerns for Augeas. There are two other approaches to programmatic config file editing besides the grand unified API/storage approach that people commonly take: * Grep/sed/awk etc. your way through to make the change you need. Works for simple file formats/situations, but everybody winds up reinventing that for their specific situation, and there's usually not enough effort put into that to make sure that every possible variation of a file is processed correctly. Augeas addresses that by focusing just on the processing/editing aspect, so that for each file the description can be adapted and perfected over time (assuming it wasn't perfect to begin with ;) A lot of this is about corner cases like not getting thrown off by whitespace at the end of line etc. * Templating gets you out of parsing files and worrying about the above issues. The downside is that it introduces an ad-hoc canonical store of config data that is not the real config file; you can't edit those files anymore by hand or with a second tool (or lose your edits the next time the template engine runs) You usually also lose the flexibility to express everything that can be expressed in the 'real' config file. The limitations of these three approaches were very important in the design of Augeas, and avoiding them lead to what it is and how it works. David From mmaccana at au1.ibm.com Sun Apr 20 23:26:13 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Mon, 21 Apr 2008 09:26:13 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <20080418140143.GC28962@redhat.com> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> <1208489946.7867.178.camel@mmaccana-laptop> <20080418140143.GC28962@redhat.com> Message-ID: <1208733973.7867.216.camel@mmaccana-laptop> On Fri, 2008-04-18 at 15:01 +0100, Daniel P. Berrange wrote: > On Fri, Apr 18, 2008 at 01:39:06PM +1000, Mike MacCana wrote: > > On Thu, 2008-04-17 at 21:17 -0600, Stephen John Smoogen wrote: > > > > > On Thu, Apr 17, 2008 at 8:02 PM, Mike MacCana wrote: > > > > > > > > On Thu, 2008-04-17 at 13:07 -0700, David Lutterkort wrote: > > > > I am pleased to announce a new configuration management project: Augeas, > > > > a low-level configuration API and editing tool. > > > > > > > > Augeas' main goal is to make programmatic changes of configuration data > > > > on Linux/Unix systems simple and safe. The main stumbling stone for this > > > > is that configuration data is stored in numerous files in widely varying > > > > formats. This is both next to impossible to change and is valuable in > > > > many situations. > > > > > > > > ???The amount of effort spent creating and re-creating tools to parse, edit > > > > and transform a variety of unnecessary, unstructured data formats over the > > > > last 30 years, and to continue doing this for the next 10 years, is less > > > > than that required to: > > > > > > > > (create a standard format, proactively patch apps to support a standard > > format, make an editor for that format, and start shipping packages) > > Back in the real world people also want to be able to manage existing deployed > production applications today. Even if you convince upstream to adopt your > grand unified configuration scheme I'm not proposing to get upstream acceptance of anything. You can't fix these things without pissing a few people off - luckily, upstream doesn't ship operating systems - distributions do. Not saying tools like cfengine, puppet, augeas aren't useful solutions, but let's recognise them for what they are - bandaid solutions. Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmaccana at au1.ibm.com Sun Apr 20 23:42:29 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Mon, 21 Apr 2008 09:42:29 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208539064.3610.82.camel@localhost.localdomain> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <1208539064.3610.82.camel@localhost.localdomain> Message-ID: <1208734949.7867.231.camel@mmaccana-laptop> On Fri, 2008-04-18 at 17:17 +0000, David Lutterkort wrote: > On Fri, 2008-04-18 at 12:02 +1000, Mike MacCana wrote: > > * create an editor for that format (which handles data - settings, > > values, parents and children, rather than presentation related info > > like lines and paragraph) > > At its heart, Augeas is a tool to make writing such editors easy, easier > than starting from scratch for every format. Of course, there's also > benefit for users if they can edit many config files with the same tool > instead of having a separate tool for each config file. Excellent. Is there a possibility that Augeas could encourage, or actively patch, applications to read their configuration directly from Augeas format files? Some of the responses to me original comment agreed that a standardized config file format was incredibly useful, but hard to achieve. Distros have some real power here, and Red Hat has used this power for good in the past: * Red Hat patched KDE to support a bunch of freedesktop.org specifications (for example, notification area support) back in the day, and while a few people got their nose out of joint, the changes were ultimately accepted into upstream KDE. Red Hat just pushed for the standard first. * Ditto ISO C - some apps had to be changed for Red Hat's more standards compliant GCC 2.96, but all those apps - including the Linux kernel and mplayer - required patching to be compilable on GCC 3 anyway, and after some grumbling, the third party apps were fixed. ?Red Hat just pushed for the standard first. A distribution has never encouraged apps to standardize on a config file format. ?There's a real opportunity here. Mike > > > Using 'widely varying formats' is not 'valuable'. > > I was a little oblique .. I meant 'that config data is stored in text > files is valuable', mostly to contrast that with some other approaches > that have been proposed in the past. OK, and agreed. > > It's an unfortunate accident that wastes everyone's time with various > > horrible bandaid solutions > > I think we're all in agreement that the situation is far from the best > imaginable. That's why I chose "Augeas"[1] as the name for this ;) > > David > > [1] http://en.wikipedia.org/wiki/Augeas > > "In Greek mythology, Augeas ... was King of Elis ... He is best known for his > stables, which housed the single greatest number of cattle in the country and > had never been cleaned" > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com From mmaccana at au1.ibm.com Sun Apr 20 23:46:40 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Mon, 21 Apr 2008 09:46:40 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208539324.3610.87.camel@localhost.localdomain> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> <1208489946.7867.178.camel@mmaccana-laptop> <20080418140143.GC28962@redhat.com> <1208539324.3610.87.camel@localhost.localdomain> Message-ID: <1208735200.7867.237.camel@mmaccana-laptop> On Fri, 2008-04-18 at 17:22 +0000, David Lutterkort wrote: > On Fri, 2008-04-18 at 15:01 +0100, Daniel P. Berrange wrote: > > Even if you convince upstream to adopt your grand unified configuration scheme > > And therein lies the rub. I've been very careful to make sure that > Augeas' usability does not depend on any upstream adopting it - they > have perfectly valid reasons not to do that, starting with that they > can't tell which proposed scheme will actually work out (and therefore > deserve their support) > > Augeas (or any similar config scheme) _has_ to be workable without > upstream support - it would be great if we get some eventually [1], but > we first need to prove that Augeas is worth their effort. > > David > > [1] And for now, it would really only require them shipping a schema > with their software, i.e. plonking one text file > into /usr/share/augeas/lenses Cool. It would be really useful to see some doco online about how an upstream could support the forma - and see some sample schemas for, say, Samba / BIND / Apache HTTPD. Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmaccana at au1.ibm.com Sun Apr 20 23:51:47 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Mon, 21 Apr 2008 09:51:47 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <20080420090403.GA4482@amd.home.annexia.org> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <20080420090403.GA4482@amd.home.annexia.org> Message-ID: <1208735507.7867.243.camel@mmaccana-laptop> On Sun, 2008-04-20 at 10:04 +0100, Richard W.M. Jones wrote: > On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote: > > Using 'widely varying formats' is not 'valuable'. It's an unfortunate > > accident that wastes everyone's time with various horrible bandaid > > solutions, and occasionally makes destroying user data an 'accepted > > limitation' of tools like system-config-named. > > Different formats suit different uses, and in any case I wouldn't > trust the people who would develop this new "super-format" not to do > something stupid like using XML. > > Rich. > Admins don't like XML because vi isn't an XML editor. It's the equivalent of Microsoft Word, treating presentation and content like they're the same thing. Config files aren't logically combinations of characters, lines, and paragraphs, They're item / value pairs, sections, and subsections. This is why I mentioned creating an editor earlier. There's no reason why you need to see XML when you edit it. shouldn't be able to say 'jump to next subsection, copy this object, paste it three times' in the same way we do with lines and paragraphs in vi. I'd call it vix. Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-4-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlutter at redhat.com Mon Apr 21 00:30:31 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 21 Apr 2008 00:30:31 +0000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208734949.7867.231.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <1208539064.3610.82.camel@localhost.localdomain> <1208734949.7867.231.camel@mmaccana-laptop> Message-ID: <1208737831.3610.162.camel@localhost.localdomain> On Mon, 2008-04-21 at 09:42 +1000, Mike MacCana wrote: > Is there a possibility that Augeas could encourage, or actively patch, > applications to read their configuration directly from Augeas format > files? As I said before, there's little point in making apps use the same mechanism to just read a config file as the one used by a config editor to read and write it. > A distribution has never encouraged apps to standardize on a config file > format. ?There's a real opportunity here. The road is littered with config projects that got run over by their own ambition. In sys mgmt, premature modeling is the root of all evil. For Augeas, my ambition is to make it a tool that is useful for modifying configuration data as it exists today, and be applicable in as many situations as possible. Once we get it there, we can think about grander things; until then, being able to use Augeas with unmodified applications is imperative. David From dlutter at redhat.com Mon Apr 21 00:33:59 2008 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 21 Apr 2008 00:33:59 +0000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208735200.7867.237.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <80d7e4090804172017v6f83584esf8de799ff14a43aa@mail.gmail.com> <1208489946.7867.178.camel@mmaccana-laptop> <20080418140143.GC28962@redhat.com> <1208539324.3610.87.camel@localhost.localdomain> <1208735200.7867.237.camel@mmaccana-laptop> Message-ID: <1208738039.3610.167.camel@localhost.localdomain> On Mon, 2008-04-21 at 09:46 +1000, Mike MacCana wrote: > Cool. It would be really useful to see some doco online about how an > upstream could support the forma There's really no need for upstream support; if anybody wants that, all they need to do is ship an appropriate schema description in /usr/share/augeas/lenses[1] > - and see some sample schemas for, say, Samba / BIND / Apache HTTPD. Writing these is dearly needed. Barring that, feedback on the existing docs[2] would also be much appreciated. David [1] like the ones I have so far: http://hg.et.redhat.com/misc/augeas?cmd=manifest;manifest=ed2827402b6a7d7b623a64778a4d3292eb3b66c2;path=/lenses/ [2] The docs linked from http://augeas.net/docs/index.html under "Writing Schemas" From fj7025cf at aa.jp.fujitsu.com Mon Apr 21 08:02:30 2008 From: fj7025cf at aa.jp.fujitsu.com (Hiroyuki Kaguchi) Date: Mon, 21 Apr 2008 17:02:30 +0900 Subject: [et-mgmt-tools] [PATCH] comparing MAC address is changed to case insensitive In-Reply-To: <20080411114252.GB20572@amd.home.annexia.org> References: <47FEAF49.1090300@aa.jp.fujitsu.com> <20080411114252.GB20572@amd.home.annexia.org> Message-ID: <480C4A16.4070801@aa.jp.fujitsu.com> Hi Rich. Thank you for your advice. On 2008/04/11 20:42, Richard W.M. Jones wrote: > You also have to note that 1:2:3:4:5:6 is the same as > 01:02:03:04:05:06. Comparing MAC addresses is hard :-) I remake the patch. This patch compares two MAC addresses ignoring leading zeros. Signed-off-by: Hiroyuki Kaguchi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: compare_mac.patch URL: From Tim.Einmahl at kba.de Mon Apr 21 08:06:18 2008 From: Tim.Einmahl at kba.de (Tim.Einmahl at kba.de) Date: Mon, 21 Apr 2008 10:06:18 +0200 Subject: [et-mgmt-tools] koan-installation hangs Message-ID: <267E81812CDE28418552FFE27393707104D07861@NTEX01.kba.de> Hi, I successfully installed cobbler and I can use it to install Redhat Enterprise Linux over PXE over a dedicated interface on the cobblerserver. But I would like to also install virtual machines with koan over the public interface of the cobblerserver, where I am stuck at the moment. I can start the installation with koan, but the problem is, that the domU that is being created is not able to get an IP-Adress for the installation process over DHCP, because not in every subnet there is a DHCP-Server.So the domU should have a static ip-address for the installation process to be able to download the kickstart-file. I tried to configure /var/lib/cobbler/settings with: kernel_options: ksdevice: link lang: ' ' text: ~ ip: 192.168.0.1 netmask: 255.255.255.0 network: static device: eth0 The problem is, when the install-kernel boots, it hangs at XENBUS: Device with no driver: device/vbd/51712 XENBUS: Device with no driver: device/vif/0 Freeing unused kernel memory: 168k freed Write protecting the kernel read-only data: 360k Then nothing more happens and virt-manager only shows a blue screen. Do you have any idea what's going wrong ? Thanks in advance Kind Regards Tim From Pablo.Iranzo at redhat.com Mon Apr 21 08:12:06 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Mon, 21 Apr 2008 10:12:06 +0200 Subject: [et-mgmt-tools] koan-installation hangs In-Reply-To: <267E81812CDE28418552FFE27393707104D07861@NTEX01.kba.de> References: <267E81812CDE28418552FFE27393707104D07861@NTEX01.kba.de> Message-ID: <1208765526.17672.104.camel@iranzo.users.redhat.com> Hi Try to start an VNC installation and check VT3 and 4 for information, also try to use the full network parameters on command line and not specify any "dhcp" option on kickstart. Not tested, but have a look at --autonet parameter for Koan. Regards Pablo El lun, 21-04-2008 a las 10:06 +0200, Tim.Einmahl at kba.de escribi?: > Hi, > > I successfully installed cobbler and I can use it to install Redhat > Enterprise Linux > over PXE over a dedicated interface on the cobblerserver. > > But I would like to also install virtual machines with koan over the > public interface of the cobblerserver, where I am stuck at the moment. > > I can start the installation with koan, but the problem is, that the > domU that is being created is not able > to get an IP-Adress for the installation process over DHCP, because not > in every subnet there is a DHCP-Server.So the domU should have a static > ip-address for the installation process to be able to download the > kickstart-file. > > I tried to configure /var/lib/cobbler/settings with: > > kernel_options: > ksdevice: link > lang: ' ' > text: ~ > ip: 192.168.0.1 > netmask: 255.255.255.0 > network: static > device: eth0 > > The problem is, when the install-kernel boots, it hangs at > XENBUS: Device with no driver: device/vbd/51712 > XENBUS: Device with no driver: device/vif/0 > Freeing unused kernel memory: 168k freed > Write protecting the kernel read-only data: 360k > > Then nothing more happens and virt-manager only shows a blue screen. > > Do you have any idea what's going wrong ? > > Thanks in advance > Kind Regards > > Tim > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From rjones at redhat.com Mon Apr 21 09:39:39 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Apr 2008 10:39:39 +0100 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <1208735507.7867.243.camel@mmaccana-laptop> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <20080420090403.GA4482@amd.home.annexia.org> <1208735507.7867.243.camel@mmaccana-laptop> Message-ID: <20080421093939.GA11027@amd.home.annexia.org> On Mon, Apr 21, 2008 at 09:51:47AM +1000, Mike MacCana wrote: > On Sun, 2008-04-20 at 10:04 +0100, Richard W.M. Jones wrote: > > On Fri, Apr 18, 2008 at 12:02:15PM +1000, Mike MacCana wrote: > > > Using 'widely varying formats' is not 'valuable'. It's an unfortunate > > > accident that wastes everyone's time with various horrible bandaid > > > solutions, and occasionally makes destroying user data an 'accepted > > > limitation' of tools like system-config-named. > > > > Different formats suit different uses, and in any case I wouldn't > > trust the people who would develop this new "super-format" not to do > > something stupid like using XML. > > > > Rich. > > > > Admins don't like XML because vi isn't an XML editor. It's the > equivalent of Microsoft Word, treating presentation and content like > they're the same thing. No, it because different formats suit different uses. XML is fine for people who never learned how to use lex & yacc. Two large anti-patterns in this area are XSLT (a programming language) and Ant (a Makefile-type tool). Compare XSLT to CDuce (XSLT done right) and Ant to plain Makefiles. Also, try converting a short example from your favorite programming language into XML to see how parsing is important. programming languages config files specialist DSLs > Config files aren't logically combinations of characters, lines, and > paragraphs, They're item / value pairs, sections, and subsections. > > This is why I mentioned creating an editor earlier. There's no reason > why you need to see XML when you edit it. shouldn't be able to say 'jump > to next subsection, copy this object, paste it three times' in the same > way we do with lines and paragraphs in vi. It's plainly ridiculous to create a whole new editor just for editing a particular form of file. This editor you're going to write is going to be better than vi & emacs? Maybe after thousands of programmers have worked on it for > 20 years. In the meantime admins will need to switch between using your editor for one particular sort of file (a small subset of configuration files on the system) versus all the other files on the system. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Mon Apr 21 09:40:24 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Apr 2008 10:40:24 +0100 Subject: [et-mgmt-tools] [PATCH] comparing MAC address is changed to case insensitive In-Reply-To: <480C4A16.4070801@aa.jp.fujitsu.com> References: <47FEAF49.1090300@aa.jp.fujitsu.com> <20080411114252.GB20572@amd.home.annexia.org> <480C4A16.4070801@aa.jp.fujitsu.com> Message-ID: <20080421094024.GB11027@amd.home.annexia.org> On Mon, Apr 21, 2008 at 05:02:30PM +0900, Hiroyuki Kaguchi wrote: > diff -r 6462dfd3e606 -r 6ec83c2a5c36 virtinst/util.py > --- a/virtinst/util.py Tue Apr 08 15:35:49 2008 -0400 > +++ b/virtinst/util.py Mon Apr 21 15:44:24 2008 +0900 > @@ -222,3 +222,22 @@ > str = str.replace("<", "<") > str = str.replace(">", ">") > return str > + > +def compareMAC(p, q): > + """Compare two MAC addresses""" > + pa = p.split(":") > + qa = q.split(":") > + > + if len(pa) != len(qa): > + if p > q: > + return 1 > + else: > + return -1 > + > + for i in xrange(len(pa)): > + n = int(pa[i], 0x10) - int(qa[i], 0x10) > + if n > 0: > + return 1 > + elif n < 0: > + return -1 > + return 0 Looks good to me, although I don't have commit access so someone else should also review this. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From mdehaan at redhat.com Mon Apr 21 14:38:27 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 10:38:27 -0400 Subject: [et-mgmt-tools] RFC Cobbler Purge command In-Reply-To: References: <80d7e4090804181227w258d471eoadd1b4287f00ea61@mail.gmail.com> <480904D3.60105@redhat.com> Message-ID: <480CA6E3.2010901@redhat.com> Jim Wildman wrote: > On Fri, 18 Apr 2008, Michael DeHaan wrote: > >> If we added a command like "cobbler system whatuses --profile=X" we >> could possibly do all sorts of clever things with xargs. That may be >> crazy though :) >> >> --Michael >> > > That one strikes me as very useful. ie, if I change this object, where > do the ripples go?? > > ------------------------------------------------------------------------ > Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com > "Society in every state is a blessing, but Government, even in its best > state, is a necessary evil; in its worst state, an intolerable one." > Thomas Paine > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools I filed this and the idea for a command line find in Trac so we won't forget this: https://fedorahosted.org/cobbler/ticket/109 https://fedorahosted.org/cobbler/ticket/110 From mdehaan at redhat.com Mon Apr 21 14:42:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 10:42:52 -0400 Subject: [et-mgmt-tools] cobbler reposync proxy issues In-Reply-To: <20080419043921.GA17236@shingen.kisoku.net> References: <20080419043921.GA17236@shingen.kisoku.net> Message-ID: <480CA7EC.7060408@redhat.com> Mathieu Sauve-Frankel wrote: > Hi, > > I'm currently using cobbler 0.8.2 from EPEL on RHEL5-x86_64. > It seems cobbler reposync does not respect proxy entries > in /etc/yum.conf. Is this expected ? > > I've temporarily worked around this by adding a file that sets > the http_proxy and ftp_proxy environment variables system-wide > in /etc/profile.d/ > > Cobbler reposync uses either yum's reposync (http/ftp) or rsync (rsync://, ssh) to do mirroring. Either way, those calls /are/ passed through the shell, so environment variables are passed along -- so your solution is fine. If you think yum's reposync is not reading import settings in /etc/yum.conf, that bug needs to be opened against yum-utils. --Michael From mdehaan at redhat.com Mon Apr 21 14:49:03 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 10:49:03 -0400 Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: <480CA95F.3070005@redhat.com> Pablo Iranzo G?mez wrote: > Hi > Attached are a patch for cobbler missing the config entry to > submited isc_set_host_name with default to 0. > > The patch for Koan is for being used with newer versions of > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > kickstart which koan uses, is "hard-coded". > > I think that the behaviour should be cobbler to provided the URL > for the kickstart, removing dependencies between cobbler and koan, or at > least, provide version number from cobbler to koan "client", for koan to > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > Regards > Pablo > > > Well, the sync code reorganization is still in progress, and as per ticket 108 which I opened up on myself, there is lots of testing to do yet :) It looks like your first koan patch is to an older version than what I had checked in, so that will not be applied. I will apply the second one about the default value missing from settings. > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Pablo.Iranzo at redhat.com Mon Apr 21 14:51:54 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Mon, 21 Apr 2008 16:51:54 +0200 Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: <480CA95F.3070005@redhat.com> References: <480CA95F.3070005@redhat.com> Message-ID: <1208789514.17672.155.camel@iranzo.users.redhat.com> Thanks! Pablo PD: Koan code was pulled from git, did you finally created a devel branch or just one "master"? El lun, 21-04-2008 a las 10:49 -0400, Michael DeHaan escribi?: > Pablo Iranzo G?mez wrote: > > Hi > > Attached are a patch for cobbler missing the config entry to > > submited isc_set_host_name with default to 0. > > > > The patch for Koan is for being used with newer versions of > > cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the > > kickstart which koan uses, is "hard-coded". > > > > I think that the behaviour should be cobbler to provided the URL > > for the kickstart, removing dependencies between cobbler and koan, or at > > least, provide version number from cobbler to koan "client", for koan to > > construct URL's for kickstart, kernel, etc appropiately. ?omments? > > > > Regards > > Pablo > > > > > > > > Well, the sync code reorganization is still in progress, and as per > ticket 108 which I opened up on myself, there is lots of testing to do > yet :) > > It looks like your first koan patch is to an older version than what I > had checked in, so that will not be applied. I will apply the second > one about the default value missing from settings. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From mdehaan at redhat.com Mon Apr 21 14:57:34 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 10:57:34 -0400 Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: <480CAB5E.10301@redhat.com> Pablo Iranzo G?mez wrote: > Hi > I've seen that Koan puts kickstart inside the initrd.img and > references it as file:ks.cfg, but I don't know the reason for this. > The reason for this is that when Anaconda restarts the NICs for the first time after BIOS, there is a rather short DHCP timeout, and depending on network issues (such as portfast config), the system may not consistantly achieve DHCP before timeout. This workaround allows for --replace-self to /always/ work because network connectivity is not needed to retrieve the kickstart. See http://fedoraproject.org/wiki/Anaconda/NetworkIssues > In order to enable auto-registration (based on > pxelinux.cfg/defaults entries), the ks should we changed by this diff on > koan/app.py: > It is true that this will bypass auto-registration, but this will only affect reinstalls, which do not update the regisration information anyway. My main concern for auto-registration is initial machine provisioning and new virt machines, so I suspect this is not a huge limitation. We could /possibly/ add a helper flag for --replace-self called "--embed-kickstart" and make the default to not do that, though as many times as it comes up, I believe the kickstart embedding is useful. Now, folks might ask "why not just do registration via a wget" in %pre, but that's apparently not valid because mac address information is not passed along in %pre scripts -- and we do want that data. > > -------------------------------------------------------------------- > > @@ -782,7 +779,7 @@ class Koan: > if not os.path.exists("/sbin/grubby"): > raise InfoException, "grubby is not installed" > k_args = > self.safe_load(profile_data,'kernel_options',default='') > - k_args = k_args + " ks=file:ks.cfg" > + k_args = k_args + " ks=" + profile_data["kickstart"] > > kickstart = self.safe_load(profile_data,'kickstart') > > -------------------------------------------------------------------- > > So the ks= would be constructed with the cobbler-provided ks > > Regards > Pablo > > > > > > From mdehaan at redhat.com Mon Apr 21 14:59:29 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 10:59:29 -0400 Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: References: Message-ID: <480CABD1.10306@redhat.com> Pablo Iranzo G?mez wrote: > Forgot, this just happens if specifying --profile on command line. > > If doing specifying "system" I got: > > libvir: XML error : line 10: EntityRef: expecting ';' > libvir: Xen Daemon error : XML description for domain is not well formed or invalid > virDomainCreateLinux() failed XML description for domain is not well > formed or invalid > > Regards > Pablo > > > > As I mentioned earlier, there is a more recent version in git that already has some of this in, so I'm not applying the above. That being said, I'm also not done with comprehensive testing on all of this newness, so I would advise waiting a bit. Soon :) --Michael From mdehaan at redhat.com Mon Apr 21 15:02:34 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 11:02:34 -0400 Subject: [et-mgmt-tools] Patches for cobbler and koan (for cobbler 0.9x) In-Reply-To: <1208789514.17672.155.camel@iranzo.users.redhat.com> References: <480CA95F.3070005@redhat.com> <1208789514.17672.155.camel@iranzo.users.redhat.com> Message-ID: <480CAC8A.3080706@redhat.com> Pablo Iranzo G?mez wrote: > Thanks! > Pablo > PD: Koan code was pulled from git, did you finally created a devel > branch or just one "master"? > Koan still only has a 'master', since it does not change very often. It is a good idea to branch it when we start doing stable for koan at 1.0. --Michael > > El lun, 21-04-2008 a las 10:49 -0400, Michael DeHaan escribi?: > >> Pablo Iranzo G?mez wrote: >> >>> Hi >>> Attached are a patch for cobbler missing the config entry to >>> submited isc_set_host_name with default to 0. >>> >>> The patch for Koan is for being used with newer versions of >>> cobbler 0.9x after Michael's patch for "svc/op=ks", as the path for the >>> kickstart which koan uses, is "hard-coded". >>> >>> I think that the behaviour should be cobbler to provided the URL >>> for the kickstart, removing dependencies between cobbler and koan, or at >>> least, provide version number from cobbler to koan "client", for koan to >>> construct URL's for kickstart, kernel, etc appropiately. ?omments? >>> >>> Regards >>> Pablo >>> >>> >>> >>> >> Well, the sync code reorganization is still in progress, and as per >> ticket 108 which I opened up on myself, there is lots of testing to do >> yet :) >> >> It looks like your first koan patch is to an older version than what I >> had checked in, so that will not be applied. I will apply the second >> one about the default value missing from settings. >> >> >> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Mon Apr 21 15:04:01 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 11:04:01 -0400 Subject: [et-mgmt-tools] Patch to reenable memtest entry creation on Cobbler 0.9 In-Reply-To: References: Message-ID: <480CACE1.7080608@redhat.com> Pablo Iranzo G?mez wrote: > Hi > This should be applied to fix the memtest entry creation on > cobbler 0.9x after moving memtest to images/ > > Regards > Pablo > Applied, thanks! > > diff --git a/cobbler/pxegen.py b/cobbler/pxegen.py > index 527b6a2..e39fdc8 100644 > --- a/cobbler/pxegen.py > +++ b/cobbler/pxegen.py > @@ -186,7 +186,7 @@ class PXEGen: > memtests = glob.glob(self.bootloc + "/images/memtest*") > if len(memtests) > 0: > pxe_menu_items = pxe_menu_items + "\n\n" > - for memtest in glob.glob(self.bootloc + '/memtest*'): > + for memtest in glob.glob(self.bootloc + '/images/memtest*'): > base = os.path.basename(memtest) > contents = self.write_memtest_pxe("/images/%s" % base) > pxe_menu_items = pxe_menu_items + contents + "\n" > > > > > From crobinso at redhat.com Mon Apr 21 20:39:02 2008 From: crobinso at redhat.com (Cole Robinson) Date: Mon, 21 Apr 2008 16:39:02 -0400 Subject: [et-mgmt-tools] [PATCH] comparing MAC address is changed to case insensitive In-Reply-To: <480C4A16.4070801@aa.jp.fujitsu.com> References: <47FEAF49.1090300@aa.jp.fujitsu.com> <20080411114252.GB20572@amd.home.annexia.org> <480C4A16.4070801@aa.jp.fujitsu.com> Message-ID: <480CFB66.2070202@redhat.com> Hiroyuki Kaguchi wrote: > Hi Rich. > > Thank you for your advice. > > On 2008/04/11 20:42, Richard W.M. Jones wrote: > > You also have to note that 1:2:3:4:5:6 is the same as > > 01:02:03:04:05:06. Comparing MAC addresses is hard :-) > > I remake the patch. > This patch compares two MAC addresses ignoring leading zeros. > > Signed-off-by: Hiroyuki Kaguchi > > I've applied this. http://hg.et.redhat.com/virt/applications/virtinst--devel?cs=a33443874046 Thanks! Cole From mdehaan at redhat.com Mon Apr 21 21:01:55 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 21 Apr 2008 17:01:55 -0400 Subject: [et-mgmt-tools] Cobbler, findks.cgi, registration, and so forth In-Reply-To: References: <4808CAC4.9020908@redhat.com> <4808F737.5040102@imageworks.com> <480926E5.1050006@redhat.com> <4809272E.7040400@redhat.com> Message-ID: <480D00C3.7060405@redhat.com> Pablo Iranzo G?mez wrote: > Hi > This auto-registration feature seems not to work if using koan to > replace a machine, as it relies on MAC and: > Correct, it pre-downloads the kickstart. This was why I mentioned possibly having an option not to embed the kickstart earlier, though /that/ wouldn't work if you rely on koan embedding the kickstart for DHCP reasons. > koan -r downloads the file using wget to store it, so no mac info > sent, machine would be correctly deployed, but no ks request will be made > by anaconda, so no autoregistration. > > wget in kickstart profile, also, doesn't send mac, so this will > not register the machine. > Indeed. It needs to make that request on the kernel options line so Anaconda adds that info. As I mentioned earlier today, this is all in progress, stay tuned and check back around Wednesday :) From agx at sigxcpu.org Tue Apr 22 14:06:23 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Tue, 22 Apr 2008 16:06:23 +0200 Subject: [et-mgmt-tools] [PATCH] virt-viewer: call gtk_init earlier Message-ID: <20080422140623.GA2769@bogon.ms20.nix> ...this allows to pass gtk specific options like --sync since since they will be stripped from argv by gtk_init. Please apply, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: call-gtk-init-early.diff Type: text/x-diff Size: 505 bytes Desc: not available URL: From berrange at redhat.com Tue Apr 22 14:16:09 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 22 Apr 2008 15:16:09 +0100 Subject: [et-mgmt-tools] [PATCH] virt-viewer: call gtk_init earlier In-Reply-To: <20080422140623.GA2769@bogon.ms20.nix> References: <20080422140623.GA2769@bogon.ms20.nix> Message-ID: <20080422141609.GD27825@redhat.com> On Tue, Apr 22, 2008 at 04:06:23PM +0200, Guido G?nther wrote: > ...this allows to pass gtk specific options like --sync since since they > will be stripped from argv by gtk_init. Thanks, I have applied this. virt-viewer should really be changed so that it uses the GTK option parsing code instead of getopt(). For that matter, so should virt-manager. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Tue Apr 22 14:43:08 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 22 Apr 2008 10:43:08 -0400 Subject: [et-mgmt-tools] [PATCH]: Make virt-viewer ungrab the mouse and keyboard on un-focus In-Reply-To: <4809486B.2070600@redhat.com> References: <4809486B.2070600@redhat.com> Message-ID: <480DF97C.2080001@redhat.com> Chris Lalancette wrote: > The attached patch prevents this situation by doing a forced ungrab when we get > a focus-out-event from GTK. > > Signed-off-by: Chris Lalancette Any interest in this patch? Chris Lalancette From berrange at redhat.com Tue Apr 22 14:49:57 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 22 Apr 2008 15:49:57 +0100 Subject: [et-mgmt-tools] [PATCH]: Make virt-viewer ungrab the mouse and keyboard on un-focus In-Reply-To: <480DF97C.2080001@redhat.com> References: <4809486B.2070600@redhat.com> <480DF97C.2080001@redhat.com> Message-ID: <20080422144957.GG27825@redhat.com> On Tue, Apr 22, 2008 at 10:43:08AM -0400, Chris Lalancette wrote: > Chris Lalancette wrote: > > The attached patch prevents this situation by doing a forced ungrab when we get > > a focus-out-event from GTK. > > > > Signed-off-by: Chris Lalancette > > Any interest in this patch? I struggle to understand how/what you managed todo here. If the keyboard grab is active nothing should be able to steal keyboard input focus, since this is the whole point of keyboard grab. If something did manage to steal keyboard input while grab was active, then this is a bug in the window manager and not something we should hack in virt-viewer - inded if this is possible, then every single app which uses grabs needs your patch which is clearly non-scalable Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Tue Apr 22 15:57:33 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 22 Apr 2008 11:57:33 -0400 Subject: [et-mgmt-tools] [PATCH]: Make virt-viewer ungrab the mouse and keyboard on un-focus In-Reply-To: <20080422144957.GG27825@redhat.com> References: <4809486B.2070600@redhat.com> <480DF97C.2080001@redhat.com> <20080422144957.GG27825@redhat.com> Message-ID: <480E0AED.6060208@redhat.com> Daniel P. Berrange wrote: > I struggle to understand how/what you managed todo here. If the keyboard > grab is active nothing should be able to steal keyboard input focus, since > this is the whole point of keyboard grab. If something did manage to steal > keyboard input while grab was active, then this is a bug in the window > manager and not something we should hack in virt-viewer - inded if this > is possible, then every single app which uses grabs needs your patch which > is clearly non-scalable This arguably is some sort of window manager bug, or possibly a bug in the way keyboard grab is currently working. In any case, it is very easy to reproduce. Just do something like: # virt-viewer guest1 & sleep 10 ; virt-viewer guest2 And make sure to click inside the guest1 virt-viewer window right after it pops up. Assuming your keyboard is grabbed there, and that your window manager placed the guest2 window on top of the guest1 window, you will be unable to escape (with Ctrl-Alt) from the guest1 window. Chris Lalancette From mdehaan at redhat.com Tue Apr 22 22:46:21 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 Apr 2008 18:46:21 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 Message-ID: <480E6ABD.7000208@redhat.com> I was talking to Dan yesterday on OFTC about how to express query strings in libvirt. Basically the new Cobbler wants to generate kickstarts on the fly, and also do some fun things about remote registration. This already works for PXE but I am having trouble passing the kernel options line into libvirt still. What I was trying was: For instance: ks=http://server.example.com/blah?op=ks&profile=blah [OR] ks=http://server.example.com/blah?op=ks;profile=blah Under F9, this works for me correctly when I use the former method and do extra = extra.replace("&","&") However I have recieved reports today that the above does not work on EL-5.1, where it (also replicated with virsh) chokes -- giving a message that the end of the XML was unexpected (see pastebin below). I am thinking the XML escaping built into virt-install/libvirt may not be the same in EL-5.1? So I knew that query strings can also be delimited by colons, but that too fails. If the form with the semicolon is easier, how would I express that with correct escaping so that calls to virtinst worked in both EL-5 and F-9? Here is the error we are seeing from the latter query string form on 5.1 http://cobbler.pastebin.com/db0f8c7a Help? The last resort is to do something funky and make cobbler tolerate URLs that do not contain any form of "?", "=", "&", and ";", but I would like to stick to the RFCs for query string formatting if possible. I do know that will work however, but if I need to do OS detection and make calls into libvirt differently that would be doable also (and maybe preferred). Thanks! --Michael From Pablo.Iranzo at redhat.com Tue Apr 22 23:00:01 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Wed, 23 Apr 2008 01:00:01 +0200 (CEST) Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E6ABD.7000208@redhat.com> References: <480E6ABD.7000208@redhat.com> Message-ID: Hi Probably this one is more descriptive (koan generation, virsh test and xml file for virsh dumped from koan.log) http://cobbler.pastebin.com/f50f3fa63 The xml is the one dumped on ~/.koan/koan.log Regards Pablo -- Pablo Iranzo G??mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar?? On Tue, 22 Apr 2008, Michael DeHaan wrote: > I was talking to Dan yesterday on OFTC about how to express query > strings in libvirt. Basically the new Cobbler wants to generate > kickstarts on the fly, and also do some fun things about remote > registration. This already works for PXE but I am having trouble > passing the kernel options line into libvirt still. What I was trying was: > > For instance: > ks=http://server.example.com/blah?op=ks&profile=blah [OR] > ks=http://server.example.com/blah?op=ks;profile=blah > > Under F9, this works for me correctly when I use the former method and do > > extra = extra.replace("&","&") > > However I have recieved reports today that the above does not work on > EL-5.1, where it (also replicated with virsh) chokes -- giving a message > that the end of the XML was unexpected (see pastebin below). I am > thinking the XML escaping built into virt-install/libvirt may not be the > same in EL-5.1? So I knew that query strings can also be delimited by > colons, but that too fails. If the form with the semicolon is easier, > how would I express that with correct escaping so that calls to virtinst > worked in both EL-5 and F-9? > > Here is the error we are seeing from the latter query string form on 5.1 > > http://cobbler.pastebin.com/db0f8c7a > > Help? > > The last resort is to do something funky and make cobbler tolerate URLs > that do not contain any form of "?", "=", "&", and ";", but I would like > to stick to the RFCs for query string formatting if possible. I do > know that will work however, but if I need to do OS detection and make > calls into libvirt differently that would be doable also (and maybe > preferred). > > Thanks! > > --Michael > > > > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From berrange at redhat.com Tue Apr 22 23:09:15 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 23 Apr 2008 00:09:15 +0100 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E6ABD.7000208@redhat.com> References: <480E6ABD.7000208@redhat.com> Message-ID: <20080422230915.GA11236@redhat.com> On Tue, Apr 22, 2008 at 06:46:21PM -0400, Michael DeHaan wrote: > I was talking to Dan yesterday on OFTC about how to express query > strings in libvirt. Basically the new Cobbler wants to generate > kickstarts on the fly, and also do some fun things about remote > registration. This already works for PXE but I am having trouble > passing the kernel options line into libvirt still. What I was trying was: > > For instance: > ks=http://server.example.com/blah?op=ks&profile=blah [OR] > ks=http://server.example.com/blah?op=ks;profile=blah > > Under F9, this works for me correctly when I use the former method and do > > extra = extra.replace("&","&") > > However I have recieved reports today that the above does not work on > EL-5.1, where it (also replicated with virsh) chokes -- giving a message > that the end of the XML was unexpected (see pastebin below). I am > thinking the XML escaping built into virt-install/libvirt may not be the > same in EL-5.1? It isn't libvirt's job to escape the query string - it just receives the XML document which must already be valid. If you're using virt-install APIs for building the XML document, then it is virt-install's job to do attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 and Fedora 8 onwards https://bugzilla.redhat.com/show_bug.cgi?id=417051 Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Tue Apr 22 23:36:25 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 Apr 2008 19:36:25 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <20080422230915.GA11236@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> Message-ID: <480E7679.1060501@redhat.com> > If you're using virt-install > APIs for building the XML document, then it is virt-install's job to do > attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 > and Fedora 8 onwards > > https://bugzilla.redhat.com/show_bug.cgi?id=417051 > > Dan. > So looking at what I posted previously, ex: http://server.example.com/?op=ks;profile=foo ";" is (to my eyes) valid in XML. It is, right? Any idea why that may cause an error on Pablo's system? Pablo, we did confirm the version with just ";" and not "&" as the seperator did break things, correct? It would be nice if I could make that also work for 5.1 installs that were out there as it reduces one extra point of user confusion about where errors come from... --Michael From mdehaan at redhat.com Tue Apr 22 23:37:51 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 Apr 2008 19:37:51 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7679.1060501@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> Message-ID: <480E76CF.6090806@redhat.com> Michael DeHaan wrote: > >> If you're using virt-install >> APIs for building the XML document, then it is virt-install's job to do >> attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 >> and Fedora 8 onwards >> >> https://bugzilla.redhat.com/show_bug.cgi?id=417051 >> >> Dan. >> > > > > So looking at what I posted previously, ex: > > http://server.example.com/?op=ks;profile=foo > > ";" is (to my eyes) valid in XML. It is, right? Any idea why that > may cause an error on Pablo's system? > > Pablo, we did confirm the version with just ";" and not "&" as the > seperator did break things, correct? FYI -- Looking at his most recent pastebin, there's the version with the ";" in it instead. > > It would be nice if I could make that also work for 5.1 installs that > were out there as it reduces one extra point of user confusion about > where > errors come from... > > --Michael > From berrange at redhat.com Tue Apr 22 23:39:43 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 23 Apr 2008 00:39:43 +0100 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7679.1060501@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> Message-ID: <20080422233943.GC11236@redhat.com> On Tue, Apr 22, 2008 at 07:36:25PM -0400, Michael DeHaan wrote: > > > If you're using virt-install > >APIs for building the XML document, then it is virt-install's job to do > >attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 > >and Fedora 8 onwards > > > >https://bugzilla.redhat.com/show_bug.cgi?id=417051 > > > >Dan. > > > > So looking at what I posted previously, ex: > > http://server.example.com/?op=ks;profile=foo > > ";" is (to my eyes) valid in XML. It is, right? Any idea why that may > cause an error on Pablo's system? Please send the actual error message you get... Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Tue Apr 22 23:51:31 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 Apr 2008 19:51:31 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <20080422233943.GC11236@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <20080422233943.GC11236@redhat.com> Message-ID: <480E7A03.2050206@redhat.com> Daniel P. Berrange wrote: > On Tue, Apr 22, 2008 at 07:36:25PM -0400, Michael DeHaan wrote: > >>> If you're using virt-install >>> APIs for building the XML document, then it is virt-install's job to do >>> attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 >>> and Fedora 8 onwards >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=417051 >>> >>> Dan. >>> >>> >> So looking at what I posted previously, ex: >> >> http://server.example.com/?op=ks;profile=foo >> >> ";" is (to my eyes) valid in XML. It is, right? Any idea why that may >> cause an error on Pablo's system? >> > > Please send the actual error message you get... > > Dan. > Sure... http://cobbler.pastebin.com/f50f3fa63 1. libvir: Xen Daemon error : POST operation failed: (xend.err 'Invalid configuration unexpected EOF') 2. virDomainCreateLinux() failed POST operation failed: (xend.err 'Invalid configuration unexpected EOF') --Michael From berrange at redhat.com Wed Apr 23 00:01:10 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 23 Apr 2008 01:01:10 +0100 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7A03.2050206@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <20080422233943.GC11236@redhat.com> <480E7A03.2050206@redhat.com> Message-ID: <20080423000110.GE11236@redhat.com> On Tue, Apr 22, 2008 at 07:51:31PM -0400, Michael DeHaan wrote: > Daniel P. Berrange wrote: > >On Tue, Apr 22, 2008 at 07:36:25PM -0400, Michael DeHaan wrote: > > > >>>If you're using virt-install > >>>APIs for building the XML document, then it is virt-install's job to do > >>>attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 > >>>and Fedora 8 onwards > >>> > >>>https://bugzilla.redhat.com/show_bug.cgi?id=417051 > >>> > >>>Dan. > >>> > >>> > >>So looking at what I posted previously, ex: > >> > >> http://server.example.com/?op=ks;profile=foo > >> > >>";" is (to my eyes) valid in XML. It is, right? Any idea why that may > >>cause an error on Pablo's system? > >> > > > >Please send the actual error message you get... > > > >Dan. > > > > Sure... http://cobbler.pastebin.com/f50f3fa63 > > 1. > libvir: Xen Daemon error : POST operation failed: (xend.err > 'Invalid configuration unexpected EOF') > 2. > virDomainCreateLinux() failed POST operation failed: (xend.err > 'Invalid configuration unexpected EOF') This is XenD itself choking on the SEXPR being given to it. It doesn't seem to like the ';' character, for unknown reasons. Perhaps you can use a hex code instead ? Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mdehaan at redhat.com Wed Apr 23 00:12:55 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 22 Apr 2008 20:12:55 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <20080423000110.GE11236@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <20080422233943.GC11236@redhat.com> <480E7A03.2050206@redhat.com> <20080423000110.GE11236@redhat.com> Message-ID: <480E7F07.2020200@redhat.com> Daniel P. Berrange wrote: > On Tue, Apr 22, 2008 at 07:51:31PM -0400, Michael DeHaan wrote: > >> Daniel P. Berrange wrote: >> >>> On Tue, Apr 22, 2008 at 07:36:25PM -0400, Michael DeHaan wrote: >>> >>> >>>>> If you're using virt-install >>>>> APIs for building the XML document, then it is virt-install's job to do >>>>> attribute escaping. This was broken in RHEL-5.1 and is fixed for 5.2 >>>>> and Fedora 8 onwards >>>>> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=417051 >>>>> >>>>> Dan. >>>>> >>>>> >>>>> >>>> So looking at what I posted previously, ex: >>>> >>>> http://server.example.com/?op=ks;profile=foo >>>> >>>> ";" is (to my eyes) valid in XML. It is, right? Any idea why that may >>>> cause an error on Pablo's system? >>>> >>>> >>> Please send the actual error message you get... >>> >>> Dan. >>> >>> >> Sure... http://cobbler.pastebin.com/f50f3fa63 >> >> 1. >> libvir: Xen Daemon error : POST operation failed: (xend.err >> 'Invalid configuration unexpected EOF') >> 2. >> virDomainCreateLinux() failed POST operation failed: (xend.err >> 'Invalid configuration unexpected EOF') >> > > This is XenD itself choking on the SEXPR being given to it. It doesn't > seem to like the ';' character, for unknown reasons. Perhaps you can > use a hex code instead ? > > Dan. > Awesome, I'll try that. I did not think to check to see if my kernel option was valid in Lisp. :) ---- fn 1) I know SEXPR's are not just for Lisp, but that would ruin the joke. From berrange at redhat.com Wed Apr 23 00:16:55 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 23 Apr 2008 01:16:55 +0100 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7F07.2020200@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <20080422233943.GC11236@redhat.com> <480E7A03.2050206@redhat.com> <20080423000110.GE11236@redhat.com> <480E7F07.2020200@redhat.com> Message-ID: <20080423001655.GF11236@redhat.com> On Tue, Apr 22, 2008 at 08:12:55PM -0400, Michael DeHaan wrote: > Daniel P. Berrange wrote: > >On Tue, Apr 22, 2008 at 07:51:31PM -0400, Michael DeHaan wrote: > > > >This is XenD itself choking on the SEXPR being given to it. It doesn't > >seem to like the ';' character, for unknown reasons. Perhaps you can > >use a hex code instead ? > > > > Awesome, I'll try that. > > I did not think to check to see if my kernel option was valid in Lisp. :) It is valid - the kernel string we pass in the SEXPR is fully quoted so XenD should not complain about the ';'. Its parser appears to be rather braindead though :-( Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From fj7025cf at aa.jp.fujitsu.com Wed Apr 23 00:33:07 2008 From: fj7025cf at aa.jp.fujitsu.com (Hiroyuki Kaguchi) Date: Wed, 23 Apr 2008 09:33:07 +0900 Subject: [et-mgmt-tools] [PATCH] fix "--wait" option of virt-viewer. Message-ID: <480E83C3.404@aa.jp.fujitsu.com> When virt-viewer is executed specifying "--wait" option, the graphical console is not displayed even through the domain is started. The cause of this trouble is that virt-viewer try to get the vncport number from the information of the stopping domain. This patch fixes "--wait" option. Thanks, Signed-off-by: Hiroyuki Kaguchi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wait_opt.patch URL: From mmaccana at au1.ibm.com Wed Apr 23 04:58:59 2008 From: mmaccana at au1.ibm.com (Mike MacCana) Date: Wed, 23 Apr 2008 14:58:59 +1000 Subject: [et-mgmt-tools] ANNOUNCE: Augeas - a configuration API In-Reply-To: <20080421093939.GA11027@amd.home.annexia.org> References: <1208462854.24126.53.camel@localhost.localdomain> <1208484135.7867.173.camel@mmaccana-laptop> <20080420090403.GA4482@amd.home.annexia.org> <1208735507.7867.243.camel@mmaccana-laptop> <20080421093939.GA11027@amd.home.annexia.org> Message-ID: <1208926739.21216.113.camel@mmaccana-laptop> On Mon, 2008-04-21 at 10:39 +0100, Richard W.M. Jones wrote: > On Mon, Apr 21, 2008 at 09:51:47AM +1000, Mike MacCana wrote: > > Admins don't like XML because vi isn't an XML editor. It's the > > equivalent of Microsoft Word, treating presentation and content like > > they're the same thing. > > Also, try converting a short example from > your favorite programming language into XML to see how parsing is > important. We're not talking about programming language, we're talking about configuration. > > This is why I mentioned creating an editor earlier. There's no reason > > why you need to see XML when you edit it. shouldn't be able to say 'jump > > to next subsection, copy this object, paste it three times' in the same > > way we do with lines and paragraphs in vi. > > It's plainly ridiculous to create a whole new editor just for editing > a particular form of file. You haven't stated why. > This editor you're going to write is going > to be better than vi & emacs? vi already does a terrible job of editing config files, as I've previously mentioned. It's designed for words and paragraphs, mean mean nothing in config files (unless you happen to practively edit your config files so they can be edited neatly in vi, which itself is ridiculous, although common). A command line version of gconfig-editor with keybindings would already crap all over presentation-based editors like vi. A simple test: 'Delete 3 (shares|virtualhosts|domains' In vi this data would either be treated as a series of lines, or re-arranged, if the format allows, so that presentation matches content and that these items are sorted into paragraphs. In vix, you'd type a key for delete, the number 3, and a third key to tell it section (defined as an object of the level where the cursor is). > Maybe after thousands of programmers have worked on it for > 20 years. I think you're too blinded by the last 20 years to see what's wrong with presentation-based tools. Cheers, Mike ________________________________________________ Mike MacCana Technical Specialist Linux Services IBM Global Services Level 14, 60 City Rd Southgate Vic 3000 Phone: +61-3-8656-2138 Fax: +61-3-?8656-2423 Email: mmaccana at au1.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pablo.Iranzo at redhat.com Wed Apr 23 06:25:28 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Wed, 23 Apr 2008 08:25:28 +0200 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7679.1060501@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> Message-ID: <1208931928.28092.0.camel@iranzo.users.redhat.com> Michael El mar, 22-04-2008 a las 19:36 -0400, Michael DeHaan escribi?: > ";" is (to my eyes) valid in XML. It is, right? Any idea why that may > cause an error on Pablo's system? > > Pablo, we did confirm the version with just ";" and not "&" as the > seperator did break things, correct? Failed with both ";" and "&" using koan and virsh ;) > It would be nice if I could make that also work for 5.1 installs that > were out there as it reduces one extra point of user confusion about where > errors come from... +1 Pablo -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From veillard at redhat.com Wed Apr 23 07:06:26 2008 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 23 Apr 2008 03:06:26 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480E7A03.2050206@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <20080422233943.GC11236@redhat.com> <480E7A03.2050206@redhat.com> Message-ID: <20080423070626.GB23786@redhat.com> On Tue, Apr 22, 2008 at 07:51:31PM -0400, Michael DeHaan wrote: > Daniel P. Berrange wrote: > >On Tue, Apr 22, 2008 at 07:36:25PM -0400, Michael DeHaan wrote: > >>So looking at what I posted previously, ex: > >> > >> http://server.example.com/?op=ks;profile=foo > >> > >>";" is (to my eyes) valid in XML. It is, right? Any idea why that may To be a bit pedantic, no it's not valid which means conforming to a DTD and the document has no DTD, but it is well formed which is the basic first check that libvirt will do. You can verify well-formedness just by seeing no error when passwd to xmllint --noout: wei:~ -> xmllint --noout xen.xml wei:~ -> > Sure... http://cobbler.pastebin.com/f50f3fa63 > > 1. > libvir: Xen Daemon error : POST operation failed: (xend.err > 'Invalid configuration unexpected EOF') > 2. > virDomainCreateLinux() failed POST operation failed: (xend.err > 'Invalid configuration unexpected EOF') if it was passed down to xend that means that libvirt didn't spot any error. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From agx at sigxcpu.org Wed Apr 23 14:38:15 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Wed, 23 Apr 2008 16:38:15 +0200 Subject: [et-mgmt-tools] [PATCH] virt-viewer: call gtk_init earlier In-Reply-To: <20080422141609.GD27825@redhat.com> References: <20080422140623.GA2769@bogon.ms20.nix> <20080422141609.GD27825@redhat.com> Message-ID: <20080423143815.GA18423@bogon.ms20.nix> On Tue, Apr 22, 2008 at 03:16:09PM +0100, Daniel P. Berrange wrote: > Thanks, I have applied this. virt-viewer should really be changed so Thanks. > that it uses the GTK option parsing code instead of getopt(). For that > matter, so should virt-manager. Yes it should, but my GTK is too crappy to get this right in 5 minutes, so I decided to use this quick one (which is still correct even when virt-viewer moves to GTK option parsing). -- Guido From markmc at redhat.com Wed Apr 23 15:11:43 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 23 Apr 2008 16:11:43 +0100 Subject: [et-mgmt-tools] [PATCH] Remove temporary treeinfo files from /var/tmp Message-ID: # HG changeset patch # User Mark McLoughlin # Date 1208962770 -3600 # Node ID c7e565fa0b688738b9c077c4349e427501c31811 # Parent c54605ffcd7b4356b2c02c85bb2c4413eae6fa53 Remove temporary treeinfo files from /var/tmp Signed-off-by: Mark McLoughlin diff -r c54605ffcd7b -r c7e565fa0b68 virtinst/OSDistro.py --- a/virtinst/OSDistro.py Mon Apr 21 18:07:25 2008 -0400 +++ b/virtinst/OSDistro.py Wed Apr 23 15:59:30 2008 +0100 @@ -56,17 +56,22 @@ class RedHatDistro(Distro): def hasTreeinfo(self, fetcher, progresscb): # all Red Hat based distros should have .treeinfo / execute only once - if (self.treeinfo is None): - if fetcher.hasFile(".treeinfo"): - logging.debug("Detected .treeinfo file") - tmptreeinfo = fetcher.acquireFile(".treeinfo", progresscb) - self.treeinfo = ConfigParser.SafeConfigParser() - self.treeinfo.read(tmptreeinfo) - return True - else: - return False - else: + if not (self.treeinfo is None): return True + + if not fetcher.hasFile(".treeinfo"): + return False + + logging.debug("Detected .treeinfo file") + + tmptreeinfo = fetcher.acquireFile(".treeinfo", progresscb) + try: + self.treeinfo = ConfigParser.SafeConfigParser() + self.treeinfo.read(tmptreeinfo) + finally: + os.unlink(tmptreeinfo) + + return True def acquireKernel(self, fetcher, progresscb): if self.hasTreeinfo(fetcher, progresscb): From shenson at redhat.com Wed Apr 23 20:07:36 2008 From: shenson at redhat.com (Scott Henson) Date: Wed, 23 Apr 2008 16:07:36 -0400 Subject: [et-mgmt-tools] cobbler_sync_master Message-ID: <480F9708.4050200@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've attached a small script that we use to sync multiple subcobbler instances to a single master. We currently use an out of band copy mechanism to get /var/www/cobbler/ks_mirror onto all our cobbler server, but we had no way of getting cobbler to know about the distro and the attached profiles. This script will add both, without syncing any data and create the necessary symlinks in /var/www/cobbler/links. Why should you use it? We currently use it for network segmentation purposes. We have several subcobblers that serve a single part of our network and we don't want to have to import distros in each place. Instead we use snap mirroring to get /var/www/cobbler/ks_mirror out and then run cobbler_sync_master to get cobbler to create the distros and profiles in its configuration files. This can also be used to distribute the load of a single network across multiple cobblers mounting ks_mirror off the same nfs share. How do you use it? Easy! You use cobbler import to get the distro into the master server. Then when the ks_mirror files arrive on the subcobblers, you run 'cobbler_sync_master --server master.example.com'. The script will add any distros that it sees on the master that are not on the subcobbler and that the kernel has arrived for. If someone else finds this script useful I'll probably clean it up a bit and we can throw it in scripts/. If more than a few people find this useful I'd be willing to port it into cobbler core. - -- Scott Henson Red Hat Production Operations Release Engineer WVU Alum BSAE/BSME -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFID5b/cQOfHbe3DKARAhGoAKC3J9S3csZHEaPhcX7it/ObUwK1lACg7NGG LOEV4jWYsW6KF3vSJ2Gh8ic= =Bb3Q -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cobbler_sync_master URL: From ssklar at stanford.edu Wed Apr 23 20:17:21 2008 From: ssklar at stanford.edu (Sandor W. Sklar) Date: Wed, 23 Apr 2008 13:17:21 -0700 Subject: [et-mgmt-tools] cobbler_sync_master In-Reply-To: <480F9708.4050200@redhat.com> References: <480F9708.4050200@redhat.com> Message-ID: <4FAA55C8-0A9F-4D96-983C-D0CC12FFBA1C@stanford.edu> On Apr 23, 2008, at 1:07 PM, Scott Henson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've attached a small script that we use to sync multiple subcobbler > instances to a single master. We currently use an out of band copy > mechanism to get /var/www/cobbler/ks_mirror onto all our cobbler > server, but we had no way of getting cobbler to know about the > distro and the attached profiles. This script will add both, > without syncing any data and create the necessary symlinks in /var/ > www/cobbler/links. > > If someone else finds this script useful I'll probably clean it up a > bit and we can throw it in scripts/. If more than a few people find > this useful I'd be willing to port it into cobbler core. I, for one, would find this very useful. We currently have a single cobbler server, with all distros and repos stored on local disk. We're in the process of re-architecting portions of our data center's network, with the end result likely to be all of our RHEL physical boxes and Xen guests behind different firewall segments, with most of those systems accessing NFS filesystems on a private network from our NetApp. I'm not sure yet exactly how we're going to end up, but having something like this tool will definitely give us more flexibility and less duplication of (fairly) static data. So, thanks! I would find this useful; even more useful if it became a part of cobbler core, with good documentation on its use! :-) -s- From mdehaan at redhat.com Wed Apr 23 21:48:54 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 23 Apr 2008 17:48:54 -0400 Subject: [et-mgmt-tools] libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <1208931928.28092.0.camel@iranzo.users.redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <1208931928.28092.0.camel@iranzo.users.redhat.com> Message-ID: <480FAEC6.6030401@redhat.com> Pablo Iranzo G?mez wrote: > Michael > > El mar, 22-04-2008 a las 19:36 -0400, Michael DeHaan escribi?: > >> ";" is (to my eyes) valid in XML. It is, right? Any idea why that may >> cause an error on Pablo's system? >> >> Pablo, we did confirm the version with just ";" and not "&" as the >> seperator did break things, correct? >> > > Failed with both ";" and "&" using koan and virsh ;) > > >> It would be nice if I could make that also work for 5.1 installs that >> were out there as it reduces one extra point of user confusion about where >> errors come from... >> > > +1 > > Pablo > My solution was to modify my mod_python URLs from ks=http://foo.example.com/cblr/srv?op=ks&system=foo To also support and use: ks=http://foo.example.com/cblr/srv/op/ks/system/foo This gets around the libvirt bug in 5.1 and also the Xen bug. --Michael > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From robin-lists at robinbowes.com Wed Apr 23 22:54:11 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Wed, 23 Apr 2008 23:54:11 +0100 Subject: [et-mgmt-tools] Re: libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: <480FAEC6.6030401@redhat.com> References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <1208931928.28092.0.camel@iranzo.users.redhat.com> <480FAEC6.6030401@redhat.com> Message-ID: Michael DeHaan wrote: > My solution was to modify my mod_python URLs from > > ks=http://foo.example.com/cblr/srv?op=ks&system=foo > > To also support and use: > > ks=http://foo.example.com/cblr/srv/op/ks/system/foo Is that done in the cobbler code or using mod_rewrite? R. From Pablo.Iranzo at redhat.com Wed Apr 23 22:55:39 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Thu, 24 Apr 2008 00:55:39 +0200 (CEST) Subject: [et-mgmt-tools] Re: libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <1208931928.28092.0.camel@iranzo.users.redhat.com> <480FAEC6.6030401@redhat.com> Message-ID: Cobbler code, interpreted (afaik) on the service code, and the way it interacts. Koan git has also be edited to use this schema. Regards Pablo -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? On Wed, 23 Apr 2008, Robin Bowes wrote: > Michael DeHaan wrote: > > My solution was to modify my mod_python URLs from > > > > ks=http://foo.example.com/cblr/srv?op=ks&system=foo > > > > To also support and use: > > > > ks=http://foo.example.com/cblr/srv/op/ks/system/foo > > Is that done in the cobbler code or using mod_rewrite? > > R. > > _______________________________________________ > 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 Apr 23 23:18:52 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 23 Apr 2008 19:18:52 -0400 Subject: [et-mgmt-tools] Re: libvirt and query strings in EL 5.1 behaves differently than F9 In-Reply-To: References: <480E6ABD.7000208@redhat.com> <20080422230915.GA11236@redhat.com> <480E7679.1060501@redhat.com> <1208931928.28092.0.camel@iranzo.users.redhat.com> <480FAEC6.6030401@redhat.com> Message-ID: <480FC3DC.2040404@redhat.com> Robin Bowes wrote: > Michael DeHaan wrote: >> My solution was to modify my mod_python URLs from >> >> ks=http://foo.example.com/cblr/srv?op=ks&system=foo >> >> To also support and use: >> >> ks=http://foo.example.com/cblr/srv/op/ks/system/foo > > Is that done in the cobbler code or using mod_rewrite? > > R. > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Cobbler's code. No Apache configuration directives are required. The service handler also supports regular query strings but know hows to translate the "/" form if they see that instead. Cobbler's various generators also generate the "/" form of the URLs. --Michael From berrange at redhat.com Thu Apr 24 02:57:01 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Apr 2008 03:57:01 +0100 Subject: [et-mgmt-tools] [PATCH] fix "--wait" option of virt-viewer. In-Reply-To: <480E83C3.404@aa.jp.fujitsu.com> References: <480E83C3.404@aa.jp.fujitsu.com> Message-ID: <20080424025701.GA11973@redhat.com> On Wed, Apr 23, 2008 at 09:33:07AM +0900, Hiroyuki Kaguchi wrote: > When virt-viewer is executed specifying "--wait" option, the graphical > console is not displayed even through the domain is started. > The cause of this trouble is that virt-viewer try to get the vncport number > from the information of the stopping domain. > This patch fixes "--wait" option. I was a little confused at first because --wait option already works as described when I test it, but then I realized that with older XenD from version 3.0.3 libvirt uses different code and so exposes this bug. So I've applied your patch. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Apr 24 02:59:56 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 24 Apr 2008 03:59:56 +0100 Subject: [et-mgmt-tools] [PATCH] Remove temporary treeinfo files from /var/tmp In-Reply-To: References: Message-ID: <20080424025956.GB11973@redhat.com> On Wed, Apr 23, 2008 at 04:11:43PM +0100, Mark McLoughlin wrote: > # HG changeset patch > # User Mark McLoughlin > # Date 1208962770 -3600 > # Node ID c7e565fa0b688738b9c077c4349e427501c31811 > # Parent c54605ffcd7b4356b2c02c85bb2c4413eae6fa53 > Remove temporary treeinfo files from /var/tmp Thanks I have applied this. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From tobert at gmail.com Thu Apr 24 20:12:01 2008 From: tobert at gmail.com (Al Tobey) Date: Thu, 24 Apr 2008 13:12:01 -0700 Subject: [et-mgmt-tools] koan network config patch Message-ID: <5ac7acb10804241312s1e7b4a0g470fedc90a198c5c@mail.gmail.com> The attached patch adds network configuration options to koan so that it will add them to the kernel command line with --autonet. This makes it really trivial to install VM's with static networking from a profile. for vmnum in `seq -f%02g 0 99` do let ip='vmnum + 16' domU="myvm-${vmnum}" koan -v -s cobbler -n -p centos5-xen -V $domU -P vgxen00 -A --ip=192.168.9.$ip --netmask=255.255.255.0 --gateway=192.168.9.1 --hostname=$domU done While I could add the systems to cobbler with a similar loop then install using a system, I don't really want to track all of these VM's in cobbler. Some are throw-away. Some come and go too often for it to be useful. "Just use DHCP" is not the answer, due to a number of issues, both technical and historical. -Al -------------- next part -------------- A non-text attachment was scrubbed... Name: koan.patch Type: application/octet-stream Size: 1375 bytes Desc: not available URL: From dmourati at gmail.com Thu Apr 24 21:14:45 2008 From: dmourati at gmail.com (Demetri Mouratis) Date: Thu, 24 Apr 2008 14:14:45 -0700 Subject: [et-mgmt-tools] koan network config patch In-Reply-To: <5ac7acb10804241312s1e7b4a0g470fedc90a198c5c@mail.gmail.com> References: <5ac7acb10804241312s1e7b4a0g470fedc90a198c5c@mail.gmail.com> Message-ID: <3cc2cbc40804241414n747e6e48i13ba6511112bf65a@mail.gmail.com> Al, Cool! I was just in need of such a feature myself but for bare-metal installs. We allow DHCP on our "build VLAN" only. Once machines get installed with base OS, they are then customized with static IPs and hostnames then re-networked to their target VLAN, server network, DMZ, etc. This is really handy. I'll give it a shot now. -D On Thu, Apr 24, 2008 at 1:12 PM, Al Tobey wrote: > The attached patch adds network configuration options to koan so that > it will add them to the kernel command line with --autonet. This > makes it really trivial to install VM's with static networking from a > profile. > > for vmnum in `seq -f%02g 0 99` > do > let ip='vmnum + 16' > domU="myvm-${vmnum}" > koan -v -s cobbler -n -p centos5-xen -V $domU -P vgxen00 -A > --ip=192.168.9.$ip --netmask=255.255.255.0 --gateway=192.168.9.1 > --hostname=$domU > done > > While I could add the systems to cobbler with a similar loop then > install using a system, I don't really want to track all of these VM's > in cobbler. Some are throw-away. Some come and go too often for it > to be useful. "Just use DHCP" is not the answer, due to a number of > issues, both technical and historical. > > -Al > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > From takatom at jp.fujitsu.com Fri Apr 25 07:20:57 2008 From: takatom at jp.fujitsu.com (Takahashi Tomohiro) Date: Fri, 25 Apr 2008 16:20:57 +0900 Subject: [et-mgmt-tools] [PATCH][virt-manager] Enable "Printscreen" to GuestOS from Virtual Machine console menu. Message-ID: <0a7601c8a6a6$2a3e5850$776f210a@fj98229700> Hi, Virtual Machine Console can not send "Printscreen" to GuestOS from menu [Send key]-[Printscreen]. This patch fix this issue. And I checked that the others [Send key] has not a problem. Signed-off-by: Tomohiro Takahashi Thanks, Tomohiro Takahashi -------------- next part -------------- A non-text attachment was scrubbed... Name: send_key_PrintScreen.patch Type: application/octet-stream Size: 525 bytes Desc: not available URL: From agx at sigxcpu.org Fri Apr 25 13:25:07 2008 From: agx at sigxcpu.org (Guido =?iso-8859-1?Q?G=FCnther?=) Date: Fri, 25 Apr 2008 15:25:07 +0200 Subject: [et-mgmt-tools] [PATCH] virt-viewer: use gtk option parsing In-Reply-To: <20080422141609.GD27825@redhat.com> References: <20080422140623.GA2769@bogon.ms20.nix> <20080422141609.GD27825@redhat.com> Message-ID: <20080425132506.GA1148@bogon.ms20.nix> On Tue, Apr 22, 2008 at 03:16:09PM +0100, Daniel P. Berrange wrote: > On Tue, Apr 22, 2008 at 04:06:23PM +0200, Guido G?nther wrote: > > ...this allows to pass gtk specific options like --sync since since they > > will be stripped from argv by gtk_init. > > Thanks, I have applied this. virt-viewer should really be changed so > that it uses the GTK option parsing code instead of getopt(). For that > matter, so should virt-manager. The attached patch does this for virt-viewer. The nice thing is that we get the gtk-vnc options for free. Cheers, -- Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: gtk-options.diff Type: text/x-diff Size: 3908 bytes Desc: not available URL: From bleanhar at redhat.com Fri Apr 25 16:46:48 2008 From: bleanhar at redhat.com (Brenton Leanhardt) Date: Fri, 25 Apr 2008 12:46:48 -0400 Subject: [et-mgmt-tools] Restarting xen guest after koan installation Message-ID: <20080425164648.GA20348@bleanhar-jboss-dev.usersys.redhat.com> I'm having trouble getting my Xen paravirt guests to reboot after kickstarting via koan. From what I hear on IRC this is possible though I was not able to get it working with the kickstart that iranzo kindly let me borrow. Here's my configuration: RHEL 5.1 koan-0.8.0-1.el5 xen-libs-3.0.3-41.el5 kernel-xen-2.6.18-53.el5 xen-3.0.3-41.el5 Fedora 8 with Cobbler 0.8.3 After looking at the koan and virtinst code I simply don't see how it would be possible for the guest to be rebooted after installation. What led me down the path of thinking this is not a problem with my kickstart is that fact that at kickstart time 'virsh dumpxml ' shows that on_reboot is set to "destroy". This appears to be the desired behavior from looking at virtinst. I tried changing virtinst to restart after installation but the OS cmdline causes the guest to get rekicked (that's probably why it's set to "destroy"). "restart" in virtinst the OS cmdline. Is there some magical flag to koan I'm missing to make rebooting possible? For my purposes I even looked into using libvirt to change the DomU's in memory configuration at kickstart time. That doesn't seem to be possible from looking at the API (probably for good reasons). --Brenton From mdehaan at redhat.com Fri Apr 25 19:56:14 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Fri, 25 Apr 2008 15:56:14 -0400 Subject: [et-mgmt-tools] Restarting xen guest after koan installation In-Reply-To: <20080425164648.GA20348@bleanhar-jboss-dev.usersys.redhat.com> References: <20080425164648.GA20348@bleanhar-jboss-dev.usersys.redhat.com> Message-ID: <4812375E.5070208@redhat.com> Brenton Leanhardt wrote: > I'm having trouble getting my Xen paravirt guests to reboot after > kickstarting via koan. From what I hear on IRC this is possible > though I was not able to get it working with the kickstart that iranzo > kindly let me borrow. > > Here's my configuration: > RHEL 5.1 koan-0.8.0-1.el5 > xen-libs-3.0.3-41.el5 > kernel-xen-2.6.18-53.el5 > xen-3.0.3-41.el5 > > Fedora 8 with Cobbler 0.8.3 > > After looking at the koan and virtinst code I simply don't see how it > would be possible for the guest to be rebooted after installation. > What led me down the path of thinking this is not a problem with my > kickstart is that fact that at kickstart time 'virsh dumpxml ' > shows that on_reboot is set to "destroy". This appears to be the > desired behavior from looking at virtinst. I tried changing virtinst > to restart after installation but the OS cmdline causes the guest to > get rekicked (that's probably why it's set to "destroy"). "restart" > in virtinst the OS cmdline. > > Is there some magical flag to koan I'm missing to make rebooting > possible? For my purposes I even looked into using libvirt to change > the DomU's in memory configuration at kickstart time. That doesn't > seem to be possible from looking at the API (probably for good > reasons). There is a limitation in the libraries (Xen I think?) that you can't reboot a guest automatically after installation. I've wanted to work around this also. This is however, something you could script with Func, and possibly cobbler post-install triggers. --Michael > > --Brenton > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Joe_Wulf at yahoo.com Sat Apr 26 13:54:14 2008 From: Joe_Wulf at yahoo.com (Joe_Wulf) Date: Sat, 26 Apr 2008 09:54:14 -0400 Subject: [et-mgmt-tools] Restarting xen guest after koan installation In-Reply-To: <4812375E.5070208@redhat.com> References: <20080425164648.GA20348@bleanhar-jboss-dev.usersys.redhat.com> <4812375E.5070208@redhat.com> Message-ID: I'm new to cobbler, seems interesting to explore this. As for rebooting a system post-build, I have had success moving the native "/etc/rc.d/rc.local" out of the way, instantiating my own to accomplish the tasks I want via `exec`. I'm "exec"ing a secondary script, so that at the end of the processing of my other script I put "/etc/rc.d/rc.local" back, and reboot as the last thing I do. R, -Joe Wulf, CISSP, USN(RET) Senior IA Engineer ProSync Technology Group, LLC www.prosync.com -----Original Message----- From: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] On Behalf Of Michael DeHaan Sent: Friday, April 25, 2008 15:56 To: Fedora/Linux Management Tools Subject: Re: [et-mgmt-tools] Restarting xen guest after koan installation Brenton Leanhardt wrote: > I'm having trouble getting my Xen paravirt guests to reboot after > kickstarting via koan. From what I hear on IRC this is possible > though I was not able to get it working with the kickstart that iranzo > kindly let me borrow. > > Here's my configuration: > RHEL 5.1 koan-0.8.0-1.el5 > xen-libs-3.0.3-41.el5 > kernel-xen-2.6.18-53.el5 > xen-3.0.3-41.el5 > > Fedora 8 with Cobbler 0.8.3 > > After looking at the koan and virtinst code I simply don't see how it > would be possible for the guest to be rebooted after installation. > What led me down the path of thinking this is not a problem with my > kickstart is that fact that at kickstart time 'virsh dumpxml ' > shows that on_reboot is set to "destroy". This appears to be the > desired behavior from looking at virtinst. I tried changing virtinst > to restart after installation but the OS cmdline causes the guest to > get rekicked (that's probably why it's set to "destroy"). "restart" > in virtinst the OS cmdline. > > Is there some magical flag to koan I'm missing to make rebooting > possible? For my purposes I even looked into using libvirt to change > the DomU's in memory configuration at kickstart time. That doesn't > seem to be possible from looking at the API (probably for good > reasons). There is a limitation in the libraries (Xen I think?) that you can't reboot a guest automatically after installation. I've wanted to work around this also. This is however, something you could script with Func, and possibly cobbler post-install triggers. --Michael > > --Brenton > > _______________________________________________ > 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 From gjansen at redhat.com Sun Apr 27 12:57:54 2008 From: gjansen at redhat.com (Geert Jansen) Date: Sun, 27 Apr 2008 14:57:54 +0200 Subject: [et-mgmt-tools] [RFE] virtual networks without DHCP Message-ID: <48147852.9040605@redhat.com> Hi all, I think it would be nice if it were possible to create a virtual network with virt-manager without DHCP and DNS services. This is useful when you want to use a host-only network for testing a setup that includes a DHCP server. I am not sure whether this is a limitation in virt-manager or in libvirt. Regards, -- Geert Jansen Product Manager EMEA Red Hat Nederland B.V. T: +31 6 293 191 57 Printerweg 44 E: gjansen at redhat.com 3821 AD Amersfoort, NL From rjones at redhat.com Mon Apr 28 07:52:12 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 28 Apr 2008 08:52:12 +0100 Subject: [et-mgmt-tools] [RFE] virtual networks without DHCP In-Reply-To: <48147852.9040605@redhat.com> References: <48147852.9040605@redhat.com> Message-ID: <20080428075212.GA8144@amd.home.annexia.org> On Sun, Apr 27, 2008 at 02:57:54PM +0200, Geert Jansen wrote: > I think it would be nice if it were possible to create a virtual network > with virt-manager without DHCP and DNS services. This is useful when you > want to use a host-only network for testing a setup that includes a DHCP > server. > > I am not sure whether this is a limitation in virt-manager or in libvirt. It's a libvirt thing. Replies redirected to libvir-list. My understanding is that if the network doesn't contain a element in the network XML then no DHCP server will be created. http://libvirt.org/formatnetwork.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jeckersb at redhat.com Mon Apr 28 14:58:37 2008 From: jeckersb at redhat.com (John Eckersberg) Date: Mon, 28 Apr 2008 10:58:37 -0400 Subject: [et-mgmt-tools] [PATCH] BIND DNS support Message-ID: <4815E61D.6070607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Working well but probably needs a bit more cleanup... Patches to my patch are welcome :) - -- John Eckersberg Production Operations Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIFeYdO5VSO/Qqm+gRAsnuAJ4t98cCcrMgXKiKOhGkAPFSwQtehgCgwita QpgcxdSFj6qlRaGwkVymD4w= =bKNt -----END PGP SIGNATURE----- From mdehaan at redhat.com Mon Apr 28 15:34:49 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Apr 2008 11:34:49 -0400 Subject: [et-mgmt-tools] cobbler_sync_master In-Reply-To: <480F9708.4050200@redhat.com> References: <480F9708.4050200@redhat.com> Message-ID: <4815EE99.9080400@redhat.com> Scott Henson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I've attached a small script that we use to sync multiple subcobbler > instances to a single master. We currently use an out of band copy > mechanism to get /var/www/cobbler/ks_mirror onto all our cobbler > server, but we had no way of getting cobbler to know about the distro > and the attached profiles. This script will add both, without syncing > any data and create the necessary symlinks in /var/www/cobbler/links. > > Why should you use it? > We currently use it for network segmentation purposes. We have > several subcobblers that serve a single part of our network and we > don't want to have to import distros in each place. Instead we use > snap mirroring to get /var/www/cobbler/ks_mirror out and then run > cobbler_sync_master to get cobbler to create the distros and profiles > in its configuration files. This can also be used to distribute the > load of a single network across multiple cobblers mounting ks_mirror > off the same nfs share. > > How do you use it? > Easy! You use cobbler import to get the distro into the master > server. Then when the ks_mirror files arrive on the subcobblers, you > run 'cobbler_sync_master --server master.example.com'. The script > will add any distros that it sees on the master that are not on the > subcobbler and that the kernel has arrived for. > > If someone else finds this script useful I'll probably clean it up a > bit and we can throw it in scripts/. If more than a few people find > this useful I'd be willing to port it into cobbler core. > > - -- > Scott Henson > Red Hat Production Operations Release Engineer > WVU Alum BSAE/BSME > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFID5b/cQOfHbe3DKARAhGoAKC3J9S3csZHEaPhcX7it/ObUwK1lACg7NGG > LOEV4jWYsW6KF3vSJ2Gh8ic= > =Bb3Q > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Very nice. Scott, if you want, send in a patch to add it cobbler's core. I'd recommend adding a "cobbler/action_syncmaster.py" and also a "cobbler/modules/cli_syncmaster.py". If you poke around the modules directory you should see how that works in terms of adding new commands to the CLI. Might we want to call it something without "sync" in it as we already have "sync" and "reposync"? loadmaster? clonemaster? --Michael From hyclak at math.ohiou.edu Mon Apr 28 15:42:52 2008 From: hyclak at math.ohiou.edu (Matt Hyclak) Date: Mon, 28 Apr 2008 11:42:52 -0400 Subject: [et-mgmt-tools] cobbler_sync_master In-Reply-To: <4815EE99.9080400@redhat.com> References: <480F9708.4050200@redhat.com> <4815EE99.9080400@redhat.com> Message-ID: <20080428154252.GK10962@math.ohiou.edu> On Mon, Apr 28, 2008 at 11:34:49AM -0400, Michael DeHaan enlightened us: > Might we want to call it something without "sync" in it as we already > have "sync" and "reposync"? > > loadmaster? clonemaster? > cobbler replicate :-) My $0.02 Matt -- Matt Hyclak Department of Mathematics Department of Social Work Ohio University (740) 593-1263 From mdehaan at redhat.com Mon Apr 28 15:54:08 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Apr 2008 11:54:08 -0400 Subject: [et-mgmt-tools] cobbler_sync_master In-Reply-To: <20080428154252.GK10962@math.ohiou.edu> References: <480F9708.4050200@redhat.com> <4815EE99.9080400@redhat.com> <20080428154252.GK10962@math.ohiou.edu> Message-ID: <4815F320.8080309@redhat.com> Matt Hyclak wrote: > On Mon, Apr 28, 2008 at 11:34:49AM -0400, Michael DeHaan enlightened us: > >> Might we want to call it something without "sync" in it as we already >> have "sync" and "reposync"? >> >> loadmaster? clonemaster? >> >> > > cobbler replicate > > :-) > > My $0.02 > > Matt > > +1 And if it gets options later for doing rsync of ks_mirror and repo_mirror data, even better. --Michael From mdehaan at redhat.com Mon Apr 28 17:57:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Apr 2008 13:57:33 -0400 Subject: [et-mgmt-tools] koan network config patch In-Reply-To: <5ac7acb10804241312s1e7b4a0g470fedc90a198c5c@mail.gmail.com> References: <5ac7acb10804241312s1e7b4a0g470fedc90a198c5c@mail.gmail.com> Message-ID: <4816100D.1050207@redhat.com> Al Tobey wrote: > The attached patch adds network configuration options to koan so that > it will add them to the kernel command line with --autonet. This > makes it really trivial to install VM's with static networking from a > profile. > > for vmnum in `seq -f%02g 0 99` > do > let ip='vmnum + 16' > domU="myvm-${vmnum}" > koan -v -s cobbler -n -p centos5-xen -V $domU -P vgxen00 -A > --ip=192.168.9.$ip --netmask=255.255.255.0 --gateway=192.168.9.1 > --hostname=$domU > done > > While I could add the systems to cobbler with a similar loop then > install using a system, I don't really want to track all of these VM's > in cobbler. Some are throw-away. Some come and go too often for it > to be useful. "Just use DHCP" is not the answer, due to a number of > issues, both technical and historical. > > -Al > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Thanks for the patch! I would perhaps change it to only override the settings that are specified on the options line (i.e. not None), though this looks good to me. I will look into applying this shortly for 0.9/1.0. We also need to add the option for a few more overrides into koan, for when the profile is mostly correct but the koan user doesn't have access to change the profile. I believe putting --virt-type back in koan was one of those things. This also provides a good opportunity to cleanup and expand the koan docs with a few basic use cases. --Michael From smooge at gmail.com Mon Apr 28 18:04:31 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 28 Apr 2008 12:04:31 -0600 Subject: [et-mgmt-tools] [PATCH] BIND DNS support In-Reply-To: <4815E61D.6070607@redhat.com> References: <4815E61D.6070607@redhat.com> Message-ID: <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> On Mon, Apr 28, 2008 at 8:58 AM, John Eckersberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Working well but probably needs a bit more cleanup... > Well a 0 length patch usually works well. What are you wanting to patch it against? > Patches to my patch are welcome :) > > - -- > John Eckersberg > Production Operations > Red Hat, Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFIFeYdO5VSO/Qqm+gRAsnuAJ4t98cCcrMgXKiKOhGkAPFSwQtehgCgwita > QpgcxdSFj6qlRaGwkVymD4w= > =bKNt > -----END PGP SIGNATURE----- > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- 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 mdehaan at redhat.com Mon Apr 28 18:09:01 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Apr 2008 14:09:01 -0400 Subject: [et-mgmt-tools] [PATCH] BIND DNS support In-Reply-To: <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> References: <4815E61D.6070607@redhat.com> <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> Message-ID: <481612BD.90006@redhat.com> Stephen John Smoogen wrote: > On Mon, Apr 28, 2008 at 8:58 AM, John Eckersberg wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Working well but probably needs a bit more cleanup... >> >> > > Well a 0 length patch usually works well. What are you wanting to > patch it against? > > > You have run afoul of our mailman install it seems. This usually does not happen with attachments, though if you'd like to try sending the patch as text that would probably be a good idea. For simplicity in patching, emailing my address with the attachment is great too -- though I'm sure the list would like to see the patch. --Michael >> Patches to my patch are welcome :) >> >> - -- >> John Eckersberg >> Production Operations >> Red Hat, Inc. >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.7 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org >> >> iD8DBQFIFeYdO5VSO/Qqm+gRAsnuAJ4t98cCcrMgXKiKOhGkAPFSwQtehgCgwita >> QpgcxdSFj6qlRaGwkVymD4w= >> =bKNt >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> et-mgmt-tools mailing list >> et-mgmt-tools at redhat.com >> https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> >> > > > > From jeckersb at redhat.com Mon Apr 28 18:08:25 2008 From: jeckersb at redhat.com (John Eckersberg) Date: Mon, 28 Apr 2008 14:08:25 -0400 Subject: [et-mgmt-tools] [PATCH] BIND DNS support In-Reply-To: <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> References: <4815E61D.6070607@redhat.com> <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> Message-ID: <48161299.8080507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen John Smoogen wrote: | On Mon, Apr 28, 2008 at 8:58 AM, John Eckersberg wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA1 |> |> Working well but probably needs a bit more cleanup... |> | | Well a 0 length patch usually works well. What are you wanting to | patch it against? | | |> Patches to my patch are welcome :) |> |> - -- |> John Eckersberg |> Production Operations |> Red Hat, Inc. |> |> -----BEGIN PGP SIGNATURE----- |> Version: GnuPG v1.4.7 (GNU/Linux) |> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org |> |> iD8DBQFIFeYdO5VSO/Qqm+gRAsnuAJ4t98cCcrMgXKiKOhGkAPFSwQtehgCgwita |> QpgcxdSFj6qlRaGwkVymD4w= |> =bKNt |> -----END PGP SIGNATURE----- |> |> _______________________________________________ |> et-mgmt-tools mailing list |> et-mgmt-tools at redhat.com |> https://www.redhat.com/mailman/listinfo/et-mgmt-tools |> | | | Ah I think this is mailman eating my patch. Here you go: http://jeckersb.fedorapeople.org/cobbler/0001-Initial-attempt-at-supporting-BIND-DNS-management.patch /me makes note to look into upgrading mailman :) - -- John Eckersberg Production Operations Red Hat, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIFhKZO5VSO/Qqm+gRAn23AJkBeq3xMmg0apMN7+bXolb/Rj6S6ACdHhz/ yI2vCpXj3LZf3d14LXkoQT4= =OCLA -----END PGP SIGNATURE----- From robin-lists at robinbowes.com Mon Apr 28 19:04:34 2008 From: robin-lists at robinbowes.com (Robin Bowes) Date: Mon, 28 Apr 2008 20:04:34 +0100 Subject: [et-mgmt-tools] Re: [PATCH] BIND DNS support In-Reply-To: <48161299.8080507@redhat.com> References: <4815E61D.6070607@redhat.com> <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> <48161299.8080507@redhat.com> Message-ID: John, Can you add "manage_dns_mode", similar to "manage_dhcp_mode"? I'd like to see cobbler support managing DNS on systems other than bind - this would be a very small first step! R. From mdehaan at redhat.com Mon Apr 28 19:25:32 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 28 Apr 2008 15:25:32 -0400 Subject: [et-mgmt-tools] Re: [PATCH] BIND DNS support In-Reply-To: References: <4815E61D.6070607@redhat.com> <80d7e4090804281104l193207cx6f024e72da8ac194@mail.gmail.com> <48161299.8080507@redhat.com> Message-ID: <481624AC.8050707@redhat.com> Robin Bowes wrote: > John, > > Can you add "manage_dns_mode", similar to "manage_dhcp_mode"? > > I'd like to see cobbler support managing DNS on systems other than > bind - this would be a very small first step! We do need this. We actually already do this already for dnsmasq (some code in dhcpgen.py should actually be in the dnsgen.py). So we would know not to try to generate bind configs when set for dnsmasq. The future probably ends up with the individual dns and dhcp types showing up in the modules directory but with just 2 there's no reason to do that just yet. --Michael From shenson at redhat.com Tue Apr 29 04:04:03 2008 From: shenson at redhat.com (Scott Henson) Date: Tue, 29 Apr 2008 00:04:03 -0400 Subject: [et-mgmt-tools] cobbler_sync_master In-Reply-To: <4815F320.8080309@redhat.com> References: <480F9708.4050200@redhat.com> <4815EE99.9080400@redhat.com> <20080428154252.GK10962@math.ohiou.edu> <4815F320.8080309@redhat.com> Message-ID: <48169E33.3090302@redhat.com> Michael DeHaan wrote: > Matt Hyclak wrote: >> On Mon, Apr 28, 2008 at 11:34:49AM -0400, Michael DeHaan enlightened us: >> >>> Might we want to call it something without "sync" in it as we >>> already have "sync" and "reposync"? >>> loadmaster? clonemaster? >>> >>> >> >> cobbler replicate >> >> :-) >> >> My $0.02 >> >> Matt >> >> > +1 > > And if it gets options later for doing rsync of ks_mirror and > repo_mirror data, even better. Sounds like a good plan to me. I'll try to have an initial patch Thursday sometime. -- Scott Henson Red Hat Production Operations Release Engineer WVU Alum BSAE/BSME From Tim.Einmahl at kba.de Tue Apr 29 05:53:03 2008 From: Tim.Einmahl at kba.de (Tim.Einmahl at kba.de) Date: Tue, 29 Apr 2008 07:53:03 +0200 Subject: AW: [et-mgmt-tools] koan-installation hangs In-Reply-To: <1208765526.17672.104.camel@iranzo.users.redhat.com> References: <267E81812CDE28418552FFE27393707104D07861@NTEX01.kba.de> <1208765526.17672.104.camel@iranzo.users.redhat.com> Message-ID: <267E81812CDE28418552FFE27393707104D0787F@NTEX01.kba.de> Hi, the problem was a firewall rule.Silly me :) But thanks for mentioning the --autonet feature, it is very useful ! I was able to install RHEL4-xen with koan successfully. But at the moment I have a problem installing RHEL3 with koan. The CPU supports hardware virtualization, so shouldn' t I use koan -T xenfv ?? If I run this, then I get libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\\n')") virDomainCreateLinux() failed POST operation failed: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\\n')") Kind Regards Tim -----Urspr?ngliche Nachricht----- Von: et-mgmt-tools-bounces at redhat.com [mailto:et-mgmt-tools-bounces at redhat.com] Im Auftrag von Pablo Iranzo G?mez Gesendet: Montag, 21. April 2008 10:12 An: Fedora/Linux Management Tools Betreff: Re: [et-mgmt-tools] koan-installation hangs Hi Try to start an VNC installation and check VT3 and 4 for information, also try to use the full network parameters on command line and not specify any "dhcp" option on kickstart. Not tested, but have a look at --autonet parameter for Koan. Regards Pablo El lun, 21-04-2008 a las 10:06 +0200, Tim.Einmahl at kba.de escribi?: > Hi, > > I successfully installed cobbler and I can use it to install Redhat > Enterprise Linux > over PXE over a dedicated interface on the cobblerserver. > > But I would like to also install virtual machines with koan over the > public interface of the cobblerserver, where I am stuck at the moment. > > I can start the installation with koan, but the problem is, that the > domU that is being created is not able > to get an IP-Adress for the installation process over DHCP, because not > in every subnet there is a DHCP-Server.So the domU should have a static > ip-address for the installation process to be able to download the > kickstart-file. > > I tried to configure /var/lib/cobbler/settings with: > > kernel_options: > ksdevice: link > lang: ' ' > text: ~ > ip: 192.168.0.1 > netmask: 255.255.255.0 > network: static > device: eth0 > > The problem is, when the install-kernel boots, it hangs at > XENBUS: Device with no driver: device/vbd/51712 > XENBUS: Device with no driver: device/vif/0 > Freeing unused kernel memory: 168k freed > Write protecting the kernel read-only data: 360k > > Then nothing more happens and virt-manager only shows a blue screen. > > Do you have any idea what's going wrong ? > > Thanks in advance > Kind Regards > > Tim > > > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid - C.I.F. B82657941 *********************************************************************************** Hinweis: Diese E-Mail und evtl. Anhaenge wurden automatisch auf Viren geprueft und gelten als virenfrei. Ihr IT-Referat. *********************************************************************************** From mdehaan at redhat.com Tue Apr 29 13:48:05 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Apr 2008 09:48:05 -0400 Subject: AW: [et-mgmt-tools] koan-installation hangs In-Reply-To: <267E81812CDE28418552FFE27393707104D0787F@NTEX01.kba.de> References: <267E81812CDE28418552FFE27393707104D07861@NTEX01.kba.de> <1208765526.17672.104.camel@iranzo.users.redhat.com> <267E81812CDE28418552FFE27393707104D0787F@NTEX01.kba.de> Message-ID: <48172715.8090903@redhat.com> Tim.Einmahl at kba.de wrote: > Hi, > > the problem was a firewall rule.Silly me :) > > But thanks for mentioning the --autonet feature, it is very useful ! > > I was able to install RHEL4-xen with koan successfully. > > > But at the moment I have a problem installing RHEL3 with koan. > The CPU supports hardware virtualization, so shouldn' t I use > > koan -T xenfv ?? > I believe we recently indentified a bug that leaves xenfv support broken (it appears to be installing paravirt with those args), which I plan to address in the next release. What is intended to happen is that it will kick off a PXE request and ideally you will have Cobbler set up to manage PXE for the system/mac you generate. If not, it works like a regular menu based install. I'll chase this and verify this is working again in the development branch this week. --Michael > If I run this, then I get > libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\\n')") > virDomainCreateLinux() failed POST operation failed: (xend.err "Error creating domain: (2, 'Invalid kernel', 'xc_dom_find_loader: no loader found\\n')") > > > Kind Regards > > Tim > > > > From Pablo.Iranzo at redhat.com Tue Apr 29 13:58:47 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Tue, 29 Apr 2008 15:58:47 +0200 Subject: [et-mgmt-tools] COBBLER patch for DHCP host creation/deletion without restarting ISC DHCP Message-ID: <1209477527.8766.19.camel@iranzo.users.redhat.com> Hi all Regarding ticket: https://fedorahosted.org/cobbler/ticket/85 I'm submitting a patch that will need extra work from any of you willing to ;) This patch introduces two new setting options: omapi and omapi_port omapi is a protocol spoke by DHCP to perform real-time modification to entries without restarting the daemon, for doing so, it needs a new setting in your dhcp.template "omapi port" and restart of the server. After that, the code for generating the DHCP config just send those commands directly and avoids final dhcp restart. Thinks lacking: - Error checking if dhcp has no omapi enabled and cobbler configuration says so - No dhcp started - no password authentication enabled (described in omshell) - Port used is 647 as it's defined in SELinux for DHCP, but not sure if used for any other thing... but for me, it works. You can check if this works this way: -creating the entries in /var/lib/cobbler/settings and /etc/cobbler/dhcp.template. - Running cobbler sync to write new entry with "omapi port" for /etc/dhcpd.conf - Stopping dhcpd - Editing /etc/dhcpd.conf and remove all host definitions created by cobbler - Emptying /var/lib/dhcpd/dhcpd.leases - Starting dhcpd After this, you can run cobbler sync and have a look at "/var/lib/dhcpd/dhcpd.leases" and have a look at the new "host" entries which will have a "dynamic" stating that have been generated dinamically with OMAPI. As the new DHCPD.conf is generated as it was before, in case of a system restart, the host will be still there. Please, patches and comments are very welcome :) Pablo -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: omshell.diff Type: text/x-patch Size: 5833 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From mdehaan at redhat.com Tue Apr 29 14:16:59 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Apr 2008 10:16:59 -0400 Subject: [et-mgmt-tools] COBBLER patch for DHCP host creation/deletion without restarting ISC DHCP In-Reply-To: <1209477527.8766.19.camel@iranzo.users.redhat.com> References: <1209477527.8766.19.camel@iranzo.users.redhat.com> Message-ID: <48172DDB.7080403@redhat.com> Pablo Iranzo G?mez wrote: > Hi all > Regarding ticket: https://fedorahosted.org/cobbler/ticket/85 > > I'm submitting a patch that will need extra work from any of you > willing to ;) > > This patch introduces two new setting options: omapi and omapi_port > > omapi is a protocol spoke by DHCP to perform real-time modification to > entries without restarting the daemon, for doing so, it needs a new > setting in your dhcp.template "omapi port" and restart of the server. > > After that, the code for generating the DHCP config just send those > commands directly and avoids final dhcp restart. > > Thinks lacking: > > - Error checking if dhcp has no omapi enabled and cobbler configuration > says so > - No dhcp started > - no password authentication enabled (described in omshell) > - Port used is 647 as it's defined in SELinux for DHCP, but not sure if > used for any other thing... but for me, it works. > > You can check if this works this way: > > -creating the entries in /var/lib/cobbler/settings > and /etc/cobbler/dhcp.template. > > - Running cobbler sync to write new entry with "omapi port" > for /etc/dhcpd.conf > > - Stopping dhcpd > > - Editing /etc/dhcpd.conf and remove all host definitions created by > cobbler > > - Emptying /var/lib/dhcpd/dhcpd.leases > > - Starting dhcpd > > After this, you can run cobbler sync and have a look at > "/var/lib/dhcpd/dhcpd.leases" and have a look at the new "host" entries > which will have a "dynamic" stating that have been generated dinamically > with OMAPI. > > As the new DHCPD.conf is generated as it was before, in case of a > system restart, the host will be still there. > > Please, patches and comments are very welcome :) > > Pablo > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Very nice! Does anyone want to take a look at testing this? I'm looking at applying most of the submitted patches later this week (this week has been excellent in terms of cobbler contributions, thanks everyone!) -- when we do it would be nice to have this on the Wiki, including instructions of what you have to add to /etc/cobbler/dhcp.template to enable omshell. Comments on error bits: - Error checking if dhcp has no omapi enabled and cobbler configuration says so This probably generates an error from DHCP, which is probably sufficient given that if you are enabling the omapi bits that can be part of the instructions. - No dhcp started Cobbler check should look for this if manage_dhcp is enabled. So we should be covered there. - no password authentication enabled (described in omshell) How do the passwords work? - Port used is 647 as it's defined in SELinux for DHCP, but not sure if used for any other thing... but for me, it works. It appears to be reserved for "DHCP failover" in /etc/services so I think we're good to go. Thanks again! --Michael From Pablo.Iranzo at redhat.com Tue Apr 29 14:26:14 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Tue, 29 Apr 2008 16:26:14 +0200 Subject: [et-mgmt-tools] COBBLER patch for DHCP host creation/deletion without restarting ISC DHCP In-Reply-To: <48172DDB.7080403@redhat.com> References: <1209477527.8766.19.camel@iranzo.users.redhat.com> <48172DDB.7080403@redhat.com> Message-ID: <1209479174.8766.23.camel@iranzo.users.redhat.com> Hi El mar, 29-04-2008 a las 10:16 -0400, Michael DeHaan escribi?: > Very nice! > > Does anyone want to take a look at testing this? > > I'm looking at applying most of the submitted patches later this week > (this week has been excellent in terms of cobbler contributions, thanks > everyone!) -- when we do it would be nice to have this on the Wiki, > including instructions of what you have to add to > /etc/cobbler/dhcp.template to enable omshell. It's on template in RPM, will fill a wiki page ;) I promise! > Comments on error bits: > > - Error checking if dhcp has no omapi enabled and cobbler configuration > says so > > This probably generates an error from DHCP, which is probably sufficient given that if you are enabling the omapi > bits that can be part of the instructions. Yes, exactly two errors per defined host ;), no error if it didn't worked but didn't complained > > - No dhcp started > > Cobbler check should look for this if manage_dhcp is enabled. So we should be covered there. Nice > > - no password authentication enabled (described in omshell) > > How do the passwords work? Ala DNSSEC way... not tested, but you're supposed to use that shema for authentication > - Port used is 647 as it's defined in SELinux for DHCP, but not sure if > used for any other thing... but for me, it works. > > It appears to be reserved for "DHCP failover" in /etc/services so I > think we're good to go. If not, we should ask for another port enabled in DHCP SELinux policy... anyone using dhcp failover with cobbler? ;) Thanks for your comments! Pablo -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From mdehaan at redhat.com Tue Apr 29 14:56:36 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Apr 2008 10:56:36 -0400 Subject: [et-mgmt-tools] COBBLER patch for DHCP host creation/deletion without restarting ISC DHCP In-Reply-To: <1209479174.8766.23.camel@iranzo.users.redhat.com> References: <1209477527.8766.19.camel@iranzo.users.redhat.com> <48172DDB.7080403@redhat.com> <1209479174.8766.23.camel@iranzo.users.redhat.com> Message-ID: <48173724.1060305@redhat.com> >> - Port used is 647 as it's defined in SELinux for DHCP, but not sure if >> used for any other thing... but for me, it works. >> >> It appears to be reserved for "DHCP failover" in /etc/services so I >> think we're good to go. >> > > If not, we should ask for another port enabled in DHCP SELinux > policy... anyone using dhcp failover with cobbler? ;) > I believe the implication is that the protocol used for both is one of the same, and that omshell can be used for such purposes. > > Thanks for your comments! > Pablo > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From Pablo.Iranzo at redhat.com Tue Apr 29 21:25:49 2008 From: Pablo.Iranzo at redhat.com (=?UTF-8?Q?Pablo_Iranzo_G=C3=B3mez?=) Date: Tue, 29 Apr 2008 23:25:49 +0200 (CEST) Subject: [et-mgmt-tools] Cobbler patch OMAPI v2 ;) Message-ID: Hi all Attached is a second patch which joins previous two patches and adds another feature: Parses /var/lib/dhcpd/dhpcd.leases and removes any "host" entry using OMAPI as previous step to write the new ones, this is done to ensure that hosts renamed, deleted or previous ones, still exist at leases, that is... resets the state to cobbler known hosts. Comments are still welcome :) Regards! Pablo PD: Thist patch will get into ticket as previous -- Pablo Iranzo G?mez (http://Alufis35.uv.es/~iranzo/) (PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp) -- Postulado de Boling sobre la Ley de Murphy: Si se encuentra bien, no se preocupe. Se le pasar? -------------- next part -------------- A non-text attachment was scrubbed... Name: OMAPIv2.diff Type: text/x-diff Size: 6990 bytes Desc: URL: From mdehaan at redhat.com Wed Apr 30 02:27:07 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Tue, 29 Apr 2008 22:27:07 -0400 Subject: [et-mgmt-tools] Cobbler patch OMAPI v2 ;) In-Reply-To: References: Message-ID: <4817D8FB.8090404@redhat.com> Pablo Iranzo G?mez wrote: > Hi all > > Attached is a second patch which joins previous two patches and > adds another feature: > > Parses /var/lib/dhcpd/dhpcd.leases and removes any "host" entry > using OMAPI as previous step to write the new ones, this is done to > ensure that hosts renamed, deleted or previous ones, still exist at > leases, that is... resets the state to cobbler known hosts. > > Comments are still welcome :) > > Regards! > Pablo > > PD: Thist patch will get into ticket as previous > > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools Should be applied Thursday or so barring any other comments, and that will make this easier for people to test. I also need to do a test release for 0.9 soon (let's call this 0.9.1 ... there will be more test releases with some other features likely being added prior to the 1.0). Quick question -- Should omapi in settings be off by default? It only works with modifications to the dhcp.template to enable it -- though we /could/ enable that by default in the template and solve the problem. Comments from folks who use Cobbler for DHCP management? The main goal of this is to keep DHCP running throughout sync operations -- but also to allow for less reasons to ever need to do "sync". Since kickstart generation is now dynamic in 0.9/1.0, the only real reason to run sync is to rebuild some of the tftpboot tree, the rest of the "partial" data gets built each time you make a change to the associated objects (and all descendents automatically update). We can probably even make that less important as time goes on, by knowing basic things like if we add a profile, we can also quickly rebuild the pxemenus (since the number of profiles is going to be very small, etc). --Michael From Pablo.Iranzo at redhat.com Wed Apr 30 06:37:07 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Wed, 30 Apr 2008 08:37:07 +0200 Subject: [et-mgmt-tools] Cobbler patch OMAPI v2 ;) In-Reply-To: <4817D8FB.8090404@redhat.com> References: <4817D8FB.8090404@redhat.com> Message-ID: <1209537427.8766.47.camel@iranzo.users.redhat.com> Morning! El mar, 29-04-2008 a las 22:27 -0400, Michael DeHaan escribi?: > Should be applied Thursday or so barring any other comments, and that > will make this easier for people to test. I also need to do a test > release for 0.9 soon (let's call this 0.9.1 ... there will be more test > releases with some other features likely being added prior to the 1.0). Count with me for the beta-testing :) > Quick question -- Should omapi in settings be off by default? It only > works with modifications to the dhcp.template to enable it -- though we > /could/ enable that by default in the template and solve the problem. For me, as cobbler is rewriting dhcp info, should be enabled by default. This could need another check for the code I submitted yesterday to check if "manage dhcp is enabled for isc". For example, in trigger, the code is: if manage_dhcp_mode == "isc": if not omapi: if not omapi_port: rc = os.system("/sbin/service dhcpd restart") So, if manage mode is "ISC", and omapi is not enabled nor omapi_port, then it does a restart. I don't think that this could hurt anyone if already using Cobbler for managing DHCP, if not, system will just do the other tasks, but nothing about DHCP > > Comments from folks who use Cobbler for DHCP management? > > The main goal of this is to keep DHCP running throughout sync operations > -- but also to allow for less reasons to ever need to do "sync". Since > kickstart generation is now dynamic in 0.9/1.0, the only real reason to > run sync is to rebuild some of the tftpboot tree, the rest of the > "partial" data gets built each time you make a change to the associated > objects (and all descendents automatically update). Well, regarding this, right now I had to put the new stanza for cleaning leases just in case of machines removal. The best thing will be to put the code in "cobbler system add" "cobbler system remove" and "cobbler system rename" in order to just make this calls when needed, remmoving the need for the "leases-cleanup code", as the systems will get created on DHCP or removed dinamically. > We can probably even make that less important as time goes on, by > knowing basic things like if we add a profile, we can also quickly > rebuild the pxemenus (since the number of profiles is going to be very > small, etc). That would be a good point, in this way, cobbler state could just use "sync" for forcing a full cobbler files recreation just to be sure, remove possible problems, as all the other operations would get inmediate action on system . Regards Pablo PD: Attached patch adds an extra check to the DHCP leases cleanup code to check if we're doing ISC -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: OMAPIv21.diff Type: text/x-patch Size: 7818 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From eamonn.walsh at gmail.com Wed Apr 30 08:42:04 2008 From: eamonn.walsh at gmail.com (Eamonn Walsh) Date: Wed, 30 Apr 2008 09:42:04 +0100 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem Message-ID: Hi Guys, Doing some work with the cobbler api and getting the fallowing error Traceback (most recent call last): File "rpc-cobbler-test", line 20, in ? remote.modify_system(system_id, 'interfaces : mac_address', 'FF:EE:DD:CC:BB:AA', token) File "/usr/lib/python2.4/xmlrpclib.py", line 1096, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request verbose=self.__verbose File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request return self._parse_response(h.getfile(), sock) File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in _parse_response return u.close() File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close raise Fault(**self._stack[0]) xmlrpclib.Fault: Line of code causing this problem: remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) Any ideas? Using cobbler 0.8.3-3.el5 Thanks, Eamonn -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pablo.Iranzo at redhat.com Wed Apr 30 11:10:10 2008 From: Pablo.Iranzo at redhat.com (Pablo Iranzo =?ISO-8859-1?Q?G=F3mez?=) Date: Wed, 30 Apr 2008 13:10:10 +0200 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: References: Message-ID: <1209553810.8766.101.camel@iranzo.users.redhat.com> Is it possible to have the script to play with it? Will try to check how this works and possible usages :) Thanks! Pablo El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > Hi Guys, > > Doing some work with the cobbler api and getting the fallowing error > > Traceback (most recent call last): > File "rpc-cobbler-test", line 20, in ? > remote.modify_system(system_id, 'interfaces : mac_address', > 'FF:EE:DD:CC:BB:AA', token) > File "/usr/lib/python2.4/xmlrpclib > .py", line 1096, in __call__ > return self.__send(self.__name, args) > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request > verbose=self.__verbose > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request > return self._parse_response(h.getfile(), sock) > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > _parse_response > return u.close() > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > raise Fault(**self._stack[0]) > xmlrpclib.Fault: method: mac'"> > > Line of code causing this problem: > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) > > Any ideas? Using cobbler 0.8.3-3.el5 > > Thanks, > > Eamonn > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools -- Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) RHCE/Global Profesional Services Consultant Spain Phone: +34 645 01 01 49 (CET/CEST) GnuPG KeyID: 0xFAD3CF0D --- Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, 28016 Madrid, Spain Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From eamonn.walsh at gmail.com Wed Apr 30 11:24:29 2008 From: eamonn.walsh at gmail.com (Eamonn Walsh) Date: Wed, 30 Apr 2008 12:24:29 +0100 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: <1209553810.8766.101.camel@iranzo.users.redhat.com> References: <1209553810.8766.101.camel@iranzo.users.redhat.com> Message-ID: Its just a test script at the moment, I want to see what it can do system_id = remote.new_system(token) remote.modify_system(system_id,'name', 'Imatest2',token) remote.modify_system(system_id,'profile', 'Testing',token) remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) remote.save_system(system_id,token) I think the problem is because the 'mac' key is in a nested list, not sure though. On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez < Pablo.Iranzo at redhat.com> wrote: > > Is it possible to have the script to play with it? > > Will try to check how this works and possible usages :) > > Thanks! > Pablo > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > Hi Guys, > > > > Doing some work with the cobbler api and getting the fallowing error > > > > Traceback (most recent call last): > > File "rpc-cobbler-test", line 20, in ? > > remote.modify_system(system_id, 'interfaces : mac_address', > > 'FF:EE:DD:CC:BB:AA', token) > > File "/usr/lib/python2.4/xmlrpclib > > .py", line 1096, in __call__ > > return self.__send(self.__name, args) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request > > verbose=self.__verbose > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request > > return self._parse_response(h.getfile(), sock) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > _parse_response > > return u.close() > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > raise Fault(**self._stack[0]) > > xmlrpclib.Fault: > method: mac'"> > > > > Line of code causing this problem: > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > Thanks, > > > > Eamonn > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com) > RHCE/Global Profesional Services Consultant Spain > Phone: +34 645 01 01 49 (CET/CEST) > GnuPG KeyID: 0xFAD3CF0D > --- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3?D, > 28016 Madrid, Spain > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Apr 30 11:32:50 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Apr 2008 07:32:50 -0400 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: <1209553810.8766.101.camel@iranzo.users.redhat.com> References: <1209553810.8766.101.camel@iranzo.users.redhat.com> Message-ID: <481858E2.9030906@redhat.com> Pablo Iranzo G?mez wrote: > Is it possible to have the script to play with it? > > Will try to check how this works and possible usages :) > > Thanks! > Pablo > > Mac registration has been revamped. It works /very/ well in 0.9.X (the devel branch) at this point. There is a new registration enabling option in settings to turn on but it works a lot more smoothly. If you would like to play with the devel version before we have a test release, see the instructions at https://fedorahosted.org/cobbler/wiki/QuickDevelRpmBuildGuide We will have a test release probably next week with source rpms but there's no reason you couldn't try it now... > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > >> Hi Guys, >> >> Doing some work with the cobbler api and getting the fallowing error >> >> Traceback (most recent call last): >> File "rpc-cobbler-test", line 20, in ? >> remote.modify_system(system_id, 'interfaces : mac_address', >> 'FF:EE:DD:CC:BB:AA', token) >> File "/usr/lib/python2.4/xmlrpclib >> .py", line 1096, in __call__ >> return self.__send(self.__name, args) >> File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request >> verbose=self.__verbose >> File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request >> return self._parse_response(h.getfile(), sock) >> File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in >> _parse_response >> return u.close() >> File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close >> raise Fault(**self._stack[0]) >> xmlrpclib.Fault: > method: mac'"> >> >> Line of code causing this problem: >> >> remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) >> >> Any ideas? Using cobbler 0.8.3-3.el5 >> >> Thanks, >> >> Eamonn >> _______________________________________________ >> 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 From mdehaan at redhat.com Wed Apr 30 11:38:33 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Apr 2008 07:38:33 -0400 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: References: <1209553810.8766.101.camel@iranzo.users.redhat.com> Message-ID: <48185A39.20707@redhat.com> Eamonn Walsh wrote: > Its just a test script at the moment, I want to see what it can do > > system_id = remote.new_system(token) > remote.modify_system(system_id,'name', 'Imatest2',token) > remote.modify_system(system_id,'profile', 'Testing',token) > remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) > remote.save_system(system_id,token) > > I think the problem is because the 'mac' key is in a nested list, not > sure though. Ah, this is your script? Glad to see more interest in API hacking! Yes, I did some work to add this recently. Definitely check out the devel branch. If you are interested in the code, see 'remote.py' and 'services.py'. The idea was to consolidate all of the cgi-bin stuff on mod_python to simplify things. All of the mod_python code ('services.py') effectively sends requests down to cobblerd via XMLRPC ('remote.py'). Since this relies on kssendmac in the kernel options line, you won't see results from running "wget", but if you request those kickstart URLs from Anaconda registration (if enabled in settings via the new option) will occur. It has some security features in that it will not add a system if mac is already in the "database" and works by detecting the mac of the system when they request the kickstart file from the mod python kickstart generator (kickstarts are no longer statically generated on the filesystem). --Michael > > On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez > > wrote: > > > Is it possible to have the script to play with it? > > Will try to check how this works and possible usages :) > > Thanks! > Pablo > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > Hi Guys, > > > > Doing some work with the cobbler api and getting the fallowing error > > > > Traceback (most recent call last): > > File "rpc-cobbler-test", line 20, in ? > > remote.modify_system(system_id, 'interfaces : mac_address', > > 'FF:EE:DD:CC:BB:AA', token) > > File "/usr/lib/python2.4/xmlrpclib > > .py", line 1096, in __call__ > > return self.__send(self.__name, args) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request > > verbose=self.__verbose > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request > > return self._parse_response(h.getfile(), sock) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > _parse_response > > return u.close() > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > raise Fault(**self._stack[0]) > > xmlrpclib.Fault: > method: mac'"> > > > > Line of code causing this problem: > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > Thanks, > > > > Eamonn > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com > ) > RHCE/Global Profesional Services Consultant Spain > Phone: +34 645 01 01 49 (CET/CEST) > GnuPG KeyID: 0xFAD3CF0D > --- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, > planta 3?D, 28016 Madrid, Spain > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, > Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > _______________________________________________ > 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 From mdehaan at redhat.com Wed Apr 30 11:41:19 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Apr 2008 07:41:19 -0400 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: <48185A39.20707@redhat.com> References: <1209553810.8766.101.camel@iranzo.users.redhat.com> <48185A39.20707@redhat.com> Message-ID: <48185ADF.7010202@redhat.com> Michael DeHaan wrote: > Eamonn Walsh wrote: >> Its just a test script at the moment, I want to see what it can do >> >> system_id = remote.new_system(token) >> remote.modify_system(system_id,'name', 'Imatest2',token) >> remote.modify_system(system_id,'profile', 'Testing',token) >> remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) >> remote.save_system(system_id,token) >> >> I think the problem is because the 'mac' key is in a nested list, not >> sure though. > > Ah, this is your script? Glad to see more interest in API hacking! > Yes, I did some work to add this recently. Definitely check out the > devel branch. If you are interested in the code, see 'remote.py' > and 'services.py'. > The idea was to consolidate all of the cgi-bin stuff on mod_python to > simplify things. All of the mod_python code ('services.py') > effectively sends requests > down to cobblerd via XMLRPC ('remote.py'). Since this relies on > kssendmac in the kernel options line, you won't see results from > running "wget", but if you request those kickstart URLs from Anaconda > registration (if enabled in settings via the new option) will occur. > > It has some security features in that it will not add a system if mac > is already in the "database" and works by detecting the mac of the system > when they request the kickstart file from the mod python kickstart > generator (kickstarts are no longer statically generated on the > filesystem). > > --Michael In the interest of completeness, the issue is that cobbler now suppports multiple network interfaces. So your script has to use the API to modify network interfaces, which is slightly varied from the above. See remote.py on the devel branch for how that is done. The WebUI, which is written against the same XMLRPC interface, is also a good reference. (cobbler/web/CobblerWeb.py) > > >> >> On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez >> > wrote: >> >> >> Is it possible to have the script to play with it? >> >> Will try to check how this works and possible usages :) >> >> Thanks! >> Pablo >> >> El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: >> > Hi Guys, >> > >> > Doing some work with the cobbler api and getting the fallowing >> error >> > >> > Traceback (most recent call last): >> > File "rpc-cobbler-test", line 20, in ? >> > remote.modify_system(system_id, 'interfaces : mac_address', >> > 'FF:EE:DD:CC:BB:AA', token) >> > File "/usr/lib/python2.4/xmlrpclib >> > .py", line 1096, in __call__ >> > return self.__send(self.__name, args) >> > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request >> > verbose=self.__verbose >> > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request >> > return self._parse_response(h.getfile(), sock) >> > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in >> > _parse_response >> > return u.close() >> > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close >> > raise Fault(**self._stack[0]) >> > xmlrpclib.Fault: > > method: mac'"> >> > >> > Line of code causing this problem: >> > >> > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) >> > >> > Any ideas? Using cobbler 0.8.3-3.el5 >> > >> > Thanks, >> > >> > Eamonn >> > _______________________________________________ >> > et-mgmt-tools mailing list >> > et-mgmt-tools at redhat.com >> > https://www.redhat.com/mailman/listinfo/et-mgmt-tools >> -- >> >> Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com >> ) >> RHCE/Global Profesional Services Consultant Spain >> Phone: +34 645 01 01 49 (CET/CEST) >> GnuPG KeyID: 0xFAD3CF0D >> --- >> Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, >> planta 3?D, 28016 Madrid, Spain >> Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, >> Spain >> Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 >> >> _______________________________________________ >> 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 > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools From eamonn.walsh at gmail.com Wed Apr 30 11:46:24 2008 From: eamonn.walsh at gmail.com (Eamonn Walsh) Date: Wed, 30 Apr 2008 12:46:24 +0100 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: <48185ADF.7010202@redhat.com> References: <1209553810.8766.101.camel@iranzo.users.redhat.com> <48185A39.20707@redhat.com> <48185ADF.7010202@redhat.com> Message-ID: What I'm hoping to achieve here, is to register the system with cobbler on first boot, I'm planning on plugging it into a script that runs at first boot anyway. Since auto reg isn't part of cobbler 0.8.3-3.el5, I'm hoping to use this as a work around. It works fine registering the system name and profile, but falls over when I try and register the mac. Will have a snoop around in the code.. On Wed, Apr 30, 2008 at 12:41 PM, Michael DeHaan wrote: > Michael DeHaan wrote: > > > Eamonn Walsh wrote: > > > > > Its just a test script at the moment, I want to see what it can do > > > > > > system_id = remote.new_system(token) > > > remote.modify_system(system_id,'name', 'Imatest2',token) > > > remote.modify_system(system_id,'profile', 'Testing',token) > > > remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) > > > remote.save_system(system_id,token) > > > > > > I think the problem is because the 'mac' key is in a nested list, not > > > sure though. > > > > > > > Ah, this is your script? Glad to see more interest in API hacking! > > Yes, I did some work to add this recently. Definitely check out the > > devel branch. If you are interested in the code, see 'remote.py' and > > 'services.py'. > > The idea was to consolidate all of the cgi-bin stuff on mod_python to > > simplify things. All of the mod_python code ('services.py') effectively > > sends requests > > down to cobblerd via XMLRPC ('remote.py'). Since this relies on > > kssendmac in the kernel options line, you won't see results from running > > "wget", but if you request those kickstart URLs from Anaconda registration > > (if enabled in settings via the new option) will occur. > > > > It has some security features in that it will not add a system if mac is > > already in the "database" and works by detecting the mac of the system > > when they request the kickstart file from the mod python kickstart > > generator (kickstarts are no longer statically generated on the filesystem). > > > > --Michael > > > > In the interest of completeness, the issue is that cobbler now suppports > multiple network interfaces. So your script has to use the API to modify > network interfaces, which is slightly varied from the above. See remote.py > on the devel branch for how that is done. The WebUI, which is written > against the same XMLRPC interface, is also a good reference. > (cobbler/web/CobblerWeb.py) > > > > > > > > > On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez < > > > Pablo.Iranzo at redhat.com > wrote: > > > > > > > > > Is it possible to have the script to play with it? > > > > > > Will try to check how this works and possible usages :) > > > > > > Thanks! > > > Pablo > > > > > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > > > Hi Guys, > > > > > > > > Doing some work with the cobbler api and getting the fallowing > > > error > > > > > > > > Traceback (most recent call last): > > > > File "rpc-cobbler-test", line 20, in ? > > > > remote.modify_system(system_id, 'interfaces : mac_address', > > > > 'FF:EE:DD:CC:BB:AA', token) > > > > File "/usr/lib/python2.4/xmlrpclib > > > > .py", line 1096, in __call__ > > > > return self.__send(self.__name, args) > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in __request > > > > verbose=self.__verbose > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request > > > > return self._parse_response(h.getfile(), sock) > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > > > _parse_response > > > > return u.close() > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > > > raise Fault(**self._stack[0]) > > > > xmlrpclib.Fault: > > > method: mac'"> > > > > > > > > Line of code causing this problem: > > > > > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) > > > > > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > > > > > Thanks, > > > > > > > > Eamonn > > > > _______________________________________________ > > > > et-mgmt-tools mailing list > > > > et-mgmt-tools at redhat.com > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > -- > > > > > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com > > > ) > > > RHCE/Global Profesional Services Consultant Spain > > > Phone: +34 645 01 01 49 (CET/CEST) > > > GnuPG KeyID: 0xFAD3CF0D > > > --- > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, > > > planta 3?D, 28016 Madrid, Spain > > > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, > > > Spain > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eamonn.walsh at gmail.com Wed Apr 30 12:54:59 2008 From: eamonn.walsh at gmail.com (Eamonn Walsh) Date: Wed, 30 Apr 2008 13:54:59 +0100 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: References: <1209553810.8766.101.camel@iranzo.users.redhat.com> <48185A39.20707@redhat.com> <48185ADF.7010202@redhat.com> Message-ID: Just a question actually, has anyone had any success using the api to register systems with cobbler? On Wed, Apr 30, 2008 at 12:46 PM, Eamonn Walsh wrote: > What I'm hoping to achieve here, is to register the system with cobbler on > first boot, I'm planning on plugging it into a script that runs at first > boot anyway. Since auto reg isn't part of cobbler 0.8.3-3.el5, I'm hoping to > use this as a work around. > > It works fine registering the system name and profile, but falls over when > I try and register the mac. Will have a snoop around in the code.. > > > On Wed, Apr 30, 2008 at 12:41 PM, Michael DeHaan > wrote: > > > Michael DeHaan wrote: > > > > > Eamonn Walsh wrote: > > > > > > > Its just a test script at the moment, I want to see what it can do > > > > > > > > system_id = remote.new_system(token) > > > > remote.modify_system(system_id,'name', 'Imatest2',token) > > > > remote.modify_system(system_id,'profile', 'Testing',token) > > > > remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) > > > > remote.save_system(system_id,token) > > > > > > > > I think the problem is because the 'mac' key is in a nested list, > > > > not sure though. > > > > > > > > > > Ah, this is your script? Glad to see more interest in API hacking! > > > Yes, I did some work to add this recently. Definitely check out the > > > devel branch. If you are interested in the code, see 'remote.py' and > > > 'services.py'. > > > The idea was to consolidate all of the cgi-bin stuff on mod_python to > > > simplify things. All of the mod_python code ('services.py') effectively > > > sends requests > > > down to cobblerd via XMLRPC ('remote.py'). Since this relies on > > > kssendmac in the kernel options line, you won't see results from running > > > "wget", but if you request those kickstart URLs from Anaconda registration > > > (if enabled in settings via the new option) will occur. > > > > > > It has some security features in that it will not add a system if mac > > > is already in the "database" and works by detecting the mac of the system > > > when they request the kickstart file from the mod python kickstart > > > generator (kickstarts are no longer statically generated on the filesystem). > > > > > > --Michael > > > > > > > In the interest of completeness, the issue is that cobbler now suppports > > multiple network interfaces. So your script has to use the API to modify > > network interfaces, which is slightly varied from the above. See remote.py > > on the devel branch for how that is done. The WebUI, which is written > > against the same XMLRPC interface, is also a good reference. > > (cobbler/web/CobblerWeb.py) > > > > > > > > > > > > > > On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez < > > > > Pablo.Iranzo at redhat.com > wrote: > > > > > > > > > > > > Is it possible to have the script to play with it? > > > > > > > > Will try to check how this works and possible usages :) > > > > > > > > Thanks! > > > > Pablo > > > > > > > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > > > > Hi Guys, > > > > > > > > > > Doing some work with the cobbler api and getting the fallowing > > > > error > > > > > > > > > > Traceback (most recent call last): > > > > > File "rpc-cobbler-test", line 20, in ? > > > > > remote.modify_system(system_id, 'interfaces : mac_address', > > > > > 'FF:EE:DD:CC:BB:AA', token) > > > > > File "/usr/lib/python2.4/xmlrpclib > > > > > .py", line 1096, in __call__ > > > > > return self.__send(self.__name, args) > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in > > > > __request > > > > > verbose=self.__verbose > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in request > > > > > return self._parse_response(h.getfile(), sock) > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > > > > _parse_response > > > > > return u.close() > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > > > > raise Fault(**self._stack[0]) > > > > > xmlrpclib.Fault: > > > no > > > > > method: mac'"> > > > > > > > > > > Line of code causing this problem: > > > > > > > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', token) > > > > > > > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > > > > > > > Thanks, > > > > > > > > > > Eamonn > > > > > _______________________________________________ > > > > > et-mgmt-tools mailing list > > > > > et-mgmt-tools at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > -- > > > > > > > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com > > > > ) > > > > RHCE/Global Profesional Services Consultant Spain > > > > Phone: +34 645 01 01 49 (CET/CEST) > > > > GnuPG KeyID: 0xFAD3CF0D > > > > --- > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, > > > > planta 3?D, 28016 Madrid, Spain > > > > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid > > > > 28001, > > > > Spain > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eamonn.walsh at gmail.com Wed Apr 30 13:29:30 2008 From: eamonn.walsh at gmail.com (Eamonn Walsh) Date: Wed, 30 Apr 2008 14:29:30 +0100 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: References: <1209553810.8766.101.camel@iranzo.users.redhat.com> <48185A39.20707@redhat.com> <48185ADF.7010202@redhat.com> Message-ID: Just realised I'm actually talking about, Read - Write XMLRPC On Wed, Apr 30, 2008 at 1:54 PM, Eamonn Walsh wrote: > Just a question actually, has anyone had any success using the api to > register systems with cobbler? > > > > > On Wed, Apr 30, 2008 at 12:46 PM, Eamonn Walsh > wrote: > > > What I'm hoping to achieve here, is to register the system with cobbler > > on first boot, I'm planning on plugging it into a script that runs at first > > boot anyway. Since auto reg isn't part of cobbler 0.8.3-3.el5, I'm hoping to > > use this as a work around. > > > > It works fine registering the system name and profile, but falls over > > when I try and register the mac. Will have a snoop around in the code.. > > > > > > On Wed, Apr 30, 2008 at 12:41 PM, Michael DeHaan > > wrote: > > > > > Michael DeHaan wrote: > > > > > > > Eamonn Walsh wrote: > > > > > > > > > Its just a test script at the moment, I want to see what it can do > > > > > > > > > > system_id = remote.new_system(token) > > > > > remote.modify_system(system_id,'name', 'Imatest2',token) > > > > > remote.modify_system(system_id,'profile', 'Testing',token) > > > > > remote.modify_system(system_id, 'mac', 'FF:EE:DD:CC:BB:AA',token) > > > > > remote.save_system(system_id,token) > > > > > > > > > > I think the problem is because the 'mac' key is in a nested list, > > > > > not sure though. > > > > > > > > > > > > > Ah, this is your script? Glad to see more interest in API hacking! > > > > Yes, I did some work to add this recently. Definitely check out > > > > the devel branch. If you are interested in the code, see 'remote.py' and > > > > 'services.py'. > > > > The idea was to consolidate all of the cgi-bin stuff on mod_python > > > > to simplify things. All of the mod_python code ('services.py') > > > > effectively sends requests > > > > down to cobblerd via XMLRPC ('remote.py'). Since this relies on > > > > kssendmac in the kernel options line, you won't see results from running > > > > "wget", but if you request those kickstart URLs from Anaconda registration > > > > (if enabled in settings via the new option) will occur. > > > > > > > > It has some security features in that it will not add a system if > > > > mac is already in the "database" and works by detecting the mac of the > > > > system > > > > when they request the kickstart file from the mod python kickstart > > > > generator (kickstarts are no longer statically generated on the filesystem). > > > > > > > > --Michael > > > > > > > > > > In the interest of completeness, the issue is that cobbler now > > > suppports multiple network interfaces. So your script has to use the API to > > > modify network interfaces, which is slightly varied from the above. See > > > remote.py on the devel branch for how that is done. The WebUI, which is > > > written against the same XMLRPC interface, is also a good reference. > > > (cobbler/web/CobblerWeb.py) > > > > > > > > > > > > > > > > > > > On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez < > > > > > Pablo.Iranzo at redhat.com > wrote: > > > > > > > > > > > > > > > Is it possible to have the script to play with it? > > > > > > > > > > Will try to check how this works and possible usages :) > > > > > > > > > > Thanks! > > > > > Pablo > > > > > > > > > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > > > > > Hi Guys, > > > > > > > > > > > > Doing some work with the cobbler api and getting the > > > > > fallowing error > > > > > > > > > > > > Traceback (most recent call last): > > > > > > File "rpc-cobbler-test", line 20, in ? > > > > > > remote.modify_system(system_id, 'interfaces : > > > > > mac_address', > > > > > > 'FF:EE:DD:CC:BB:AA', token) > > > > > > File "/usr/lib/python2.4/xmlrpclib > > > > > > .py", line 1096, in __call__ > > > > > > return self.__send(self.__name, args) > > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in > > > > > __request > > > > > > verbose=self.__verbose > > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in > > > > > request > > > > > > return self._parse_response(h.getfile(), sock) > > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > > > > > _parse_response > > > > > > return u.close() > > > > > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > > > > > raise Fault(**self._stack[0]) > > > > > > xmlrpclib.Fault: > > > > has no > > > > > > method: mac'"> > > > > > > > > > > > > Line of code causing this problem: > > > > > > > > > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', > > > > > token) > > > > > > > > > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Eamonn > > > > > > _______________________________________________ > > > > > > et-mgmt-tools mailing list > > > > > > et-mgmt-tools at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > > > > > -- > > > > > > > > > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com > > > > > ) > > > > > RHCE/Global Profesional Services Consultant Spain > > > > > Phone: +34 645 01 01 49 (CET/CEST) > > > > > GnuPG KeyID: 0xFAD3CF0D > > > > > --- > > > > > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, > > > > > planta 3?D, 28016 Madrid, Spain > > > > > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, Madrid > > > > > 28001, > > > > > Spain > > > > > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdehaan at redhat.com Wed Apr 30 13:47:23 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Wed, 30 Apr 2008 09:47:23 -0400 Subject: [et-mgmt-tools] Cobbler API - Mac registration problem In-Reply-To: References: <1209553810.8766.101.camel@iranzo.users.redhat.com> <48185A39.20707@redhat.com> <48185ADF.7010202@redhat.com> Message-ID: <4818786B.1060706@redhat.com> Eamonn Walsh wrote: > What I'm hoping to achieve here, is to register the system with > cobbler on first boot, I'm planning on plugging it into a script that > runs at first boot anyway. Since auto reg isn't part of cobbler > 0.8.3-3.el5, I'm hoping to use this as a work around. > > It works fine registering the system name and profile, but falls over > when I try and register the mac. Will have a snoop around in the code.. You have to do auto registration via the kickstart fetcher -- as Anaconda doesn't send the MAC for all %pre/%post requests (like I previously thought...). Another thing that had to be done was to make some changes to allow those kind of URLs to be tolerated by the virt code -- so all in all, your best bet is 0.9.X. > > On Wed, Apr 30, 2008 at 12:41 PM, Michael DeHaan > wrote: > > Michael DeHaan wrote: > > Eamonn Walsh wrote: > > Its just a test script at the moment, I want to see what > it can do > > system_id = remote.new_system(token) > remote.modify_system(system_id,'name', 'Imatest2',token) > remote.modify_system(system_id,'profile', 'Testing',token) > remote.modify_system(system_id, 'mac', > 'FF:EE:DD:CC:BB:AA',token) > remote.save_system(system_id,token) > > I think the problem is because the 'mac' key is in a > nested list, not sure though. > > > Ah, this is your script? Glad to see more interest in API hacking! > Yes, I did some work to add this recently. Definitely check > out the devel branch. If you are interested in the code, see > 'remote.py' and 'services.py'. > The idea was to consolidate all of the cgi-bin stuff on > mod_python to simplify things. All of the mod_python code > ('services.py') effectively sends requests > down to cobblerd via XMLRPC ('remote.py'). Since this relies > on kssendmac in the kernel options line, you won't see results > from running "wget", but if you request those kickstart URLs > from Anaconda registration (if enabled in settings via the new > option) will occur. > > It has some security features in that it will not add a system > if mac is already in the "database" and works by detecting the > mac of the system > when they request the kickstart file from the mod python > kickstart generator (kickstarts are no longer statically > generated on the filesystem). > > --Michael > > > In the interest of completeness, the issue is that cobbler now > suppports multiple network interfaces. So your script has to use > the API to modify network interfaces, which is slightly varied > from the above. See remote.py on the devel branch for how that is > done. The WebUI, which is written against the same XMLRPC > interface, is also a good reference. (cobbler/web/CobblerWeb.py) > > > > > On Wed, Apr 30, 2008 at 12:10 PM, Pablo Iranzo G?mez > > >> wrote: > > > Is it possible to have the script to play with it? > > Will try to check how this works and possible usages :) > > Thanks! > Pablo > > El mi?, 30-04-2008 a las 09:42 +0100, Eamonn Walsh escribi?: > > Hi Guys, > > > > Doing some work with the cobbler api and getting the > fallowing error > > > > Traceback (most recent call last): > > File "rpc-cobbler-test", line 20, in ? > > remote.modify_system(system_id, 'interfaces : mac_address', > > 'FF:EE:DD:CC:BB:AA', token) > > File "/usr/lib/python2.4/xmlrpclib > > .py", line 1096, in __call__ > > return self.__send(self.__name, args) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1383, in > __request > > verbose=self.__verbose > > File "/usr/lib/python2.4/xmlrpclib.py", line 1147, in > request > > return self._parse_response(h.getfile(), sock) > > File "/usr/lib/python2.4/xmlrpclib.py", line 1286, in > > _parse_response > > return u.close() > > File "/usr/lib/python2.4/xmlrpclib.py", line 744, in close > > raise Fault(**self._stack[0]) > > xmlrpclib.Fault: "cobbler.cexceptions.CX:'object has no > > method: mac'"> > > > > Line of code causing this problem: > > > > remote.modify_system(sys_id, 'mac', 'AA:BB:CC:DD:EE:FF', > token) > > > > Any ideas? Using cobbler 0.8.3-3.el5 > > > > Thanks, > > > > Eamonn > > _______________________________________________ > > et-mgmt-tools mailing list > > et-mgmt-tools at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/et-mgmt-tools > -- > > Pablo Iranzo G?mez (Pablo.Iranzo at redhat.com > > >) > RHCE/Global Profesional Services Consultant Spain > Phone: +34 645 01 01 49 (CET/CEST) > GnuPG KeyID: 0xFAD3CF0D > --- > Direcci?n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, > planta 3?D, 28016 Madrid, Spain > Direcci?n Registrada: Red Hat S.L., C/ Velazquez 63, > Madrid 28001, > Spain > Inscrita en el Reg. Mercantil de Madrid ? C.I.F. B82657941 > > _______________________________________________ > 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 > > > _______________________________________________ > 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 > > > ------------------------------------------------------------------------ > > _______________________________________________ > et-mgmt-tools mailing list > et-mgmt-tools at redhat.com > https://www.redhat.com/mailman/listinfo/et-mgmt-tools