Re: [Spacewalk-devel] Bootstrap image feature
On 08/28/2012 12:06 PM, Jan Pazdziora wrote:
On Wed, Aug 08, 2012 at 11:29:27AM +0200, Uwe Gansert wrote:
On 02.08.2012 11:15, Jan Pazdziora wrote:
* inventing a new architecture bootstrap-linux that automatically
gets the new entitlement during registration.
Could you please explain some more why new architecture is needed?
Won't we actually need to know what architecture (the physical one)
the machine is?
I wanted to clean up the patch today and noticed, that we still need
the architecture.
The architecture is directly connected to the new
bootstrap-entitlement in the database via
rhnServerServerGroupArchCompat table:
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('bootstrap_entitled'));
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('provisioning_entitled'));
if a machine registers with that arch, it'll get the
bootstrap-entitlement automatically.
Please correct me if I'm wrong or misunderstood something but I'm
afraid, we still need the arch.
Well, the question still is, why does it have to exist at all (and be
connected)? We should be able to figure out the real architecture on
the running (bootstrapped) machine just fine.
And if we use the activation key method for adding the entitlement
instead of the bootstrap-linux, it shouldn't be needed.
I noticed that this thread died, without any patch applied to spacewalk
master. Are we still looking to re-submit?
Regards,
Cliff
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On Wed, Aug 08, 2012 at 11:29:27AM +0200, Uwe Gansert wrote:
On 02.08.2012 11:15, Jan Pazdziora wrote:
* inventing a new architecture bootstrap-linux that automatically
gets the new entitlement during registration.
Could you please explain some more why new architecture is needed?
Won't we actually need to know what architecture (the physical one)
the machine is?
I wanted to clean up the patch today and noticed, that we still need
the architecture.
The architecture is directly connected to the new
bootstrap-entitlement in the database via
rhnServerServerGroupArchCompat table:
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('bootstrap_entitled'));
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('provisioning_entitled'));
if a machine registers with that arch, it'll get the
bootstrap-entitlement automatically.
Please correct me if I'm wrong or misunderstood something but I'm
afraid, we still need the arch.
Well, the question still is, why does it have to exist at all (and be
connected)? We should be able to figure out the real architecture on
the running (bootstrapped) machine just fine.
And if we use the activation key method for adding the entitlement
instead of the bootstrap-linux, it shouldn't be needed.
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On 02.08.2012 11:15, Jan Pazdziora wrote:
* inventing a new architecture bootstrap-linux that automatically
gets the new entitlement during registration.
Could you please explain some more why new architecture is needed?
Won't we actually need to know what architecture (the physical one)
the machine is?
I wanted to clean up the patch today and noticed, that we still need the
architecture.
The architecture is directly connected to the new bootstrap-entitlement
in the database via rhnServerServerGroupArchCompat table:
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('bootstrap_entitled'));
insert into rhnServerServerGroupArchCompat ( server_arch_id,
server_group_type)
values (lookup_server_arch('bootstrap-linux'),
lookup_sg_type('provisioning_entitled'));
if a machine registers with that arch, it'll get the
bootstrap-entitlement automatically.
Please correct me if I'm wrong or misunderstood something but I'm
afraid, we still need the arch.
--
ciao, Uwe Gansert
SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg)
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net
___
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On Thu, Aug 02, 2012 at 10:42:01AM +0200, Uwe Gansert wrote: I have attached patches that fit into master. But actually they are more to show what I did and for discussion maybe. The schema-upgrade for example is still missing because I don't know yet in which version that patch will end. We are still aiming for 1.8 if we can make it. In any case, we need to commit the schema upgrades together with the schema population changes or the freshly installed and upgraded installations won't match. By keeping the schema upgrades in sync with the main schema content, we can do the release at any point, even if the feature is only half-finished. The patches are not too big but I'll explain what I did: * inventing a new base entitlement called bootstrap_entitled that has the provisioning feature * the changes in the Web UI are only for adding some ACLs that check this new entitlement and turn off some web-ui features like the Software-tab * inventing a new architecture bootstrap-linux that automatically gets the new entitlement during registration. Could you please explain some more why new architecture is needed? Won't we actually need to know what architecture (the physical one) the machine is? * patching the registration process on the server to accept registration without user/pass or reg-key when bootstrap-linux is registering. Only org_id is needed then. Couldn't we use registration keys for this? The key would be on the image that the machine would PXE boot. I'm a bit worries that extending access control logic based on some hardcoded string will lead to maintenance nightmare and potential security issue. I did not change that database with new tables or columns. Just some data is inserted for the new architecture and entitlement. the system_reg_final.py client is the registration client on the image. It's called final but it's still a development version. Important data during registration is the org_id (default is 1) and the address of the spacewalk server (default is IPAPPEND parameter) There are still some hardcoded values in there but those will be no problem an can be changed. I think we need to discuss how the image will get generated. I'm a bit concerned that by duplicating what seems to be a rhnreg_ks logic, we will end up with two code bases to maintain. If the system_reg_final.py does something which rhnreg_ks cannot do, couldn't we extend rhnreg_ks instead? If you find the time to look at it, that would be great. I hope inventing a new entitlement was a good way for that but thanks to the ACLs, the changes in the webfrontend are quite minimal because of that. The new entitlement I feel is OK. Of course, we will need to check the rest of the UI to see if other parts need to be locked down for it. Because this entitlement not only means allow some particular action, it also implcitly means if no other entitlement is present, don't show these other actions. From this point of view, I am not that sure about the rhn:require acl=not system_has_bootstrap_entitlement(); pieces -- the entitlements should add capabilities, not block them. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On 02.08.2012 11:15, Jan Pazdziora wrote: I have attached patches that fit into master. But actually they are more to show what I did and for discussion maybe. The schema-upgrade for example is still missing because I don't know yet in which version that patch will end. We are still aiming for 1.8 if we can make it. In any case, we need to commit the schema upgrades together with the schema population changes or the freshly installed and upgraded installations won't match. By keeping the schema upgrades in sync with the main schema content, we can do the release at any point, even if the feature is only half-finished. of course you are right. The schema upgrade has to be in sync with the schema. I just did not do the schema upgrade yet, because the feature is in no production branch yet. Neither here at SUSE nor at your Spacewalk. As soon as we know in which version we want to put that, we have to add the schema upgrade too - that's true. * inventing a new architecture bootstrap-linux that automatically gets the new entitlement during registration. Could you please explain some more why new architecture is needed? Won't we actually need to know what architecture (the physical one) the machine is? I don't think we need to know the physical architecture but you are right with that we don't need the architecture at all. When I started the project I thought I need an architecture but I used the release for that later and did not remove the architecture patch. Good catch. Thanks. * patching the registration process on the server to accept registration without user/pass or reg-key when bootstrap-linux is registering. Only org_id is needed then. Couldn't we use registration keys for this? The key would be on the image that the machine would PXE boot. I'm a bit worries that extending access control logic based on some hardcoded string will lead to maintenance nightmare and potential security issue. that's the stuff I want to discuss. :) I tried the registration-key version too but I'm unsure which is the better way. I did not like to hardcode a reg-key in the server and so I tried to patch it in a way that it can accept registrations with only the org_id set. I saw that the effort is not small, so I decided to go that way. How do you want to solve the reg-key way? Hardcoding a static reg-key into the server? That key should not be used by other machines (accidently) and should not be edited by the admin I think. I think we need to discuss how the image will get generated. I'm a bit yes, that's a good point. I used our internal buildservice to create an image. In the backend the buildservice will use kiwi. That's a commandline tool to create all kind of images (the complete SUSE Manager appliance is built with that too). You can create such an image on the commandline with kiwi too but I never tried to build an image on a Red Hat system. For me it's simple. More or less I only specify a collection of RPM names and in the end I'll have a kernel+initrd. Do you at Red Hat have a tool for creating such images? concerned that by duplicating what seems to be a rhnreg_ks logic, we will end up with two code bases to maintain. If the I see what you mean but the logic in the system_reg_final is so small, that I did not worry about it. I tried the rhnreg_ks way too in the beginning but a new little reg-tool just for the image was easier at the end. Enhancing rhnreg_ks should work too but the change will be bigger I'm afraid but maybe it's the cleaner way. The new client is so small that I don't see too much maintenance effort in the future though. The new entitlement I feel is OK. Of course, we will need to check the rest of the UI to see if other parts need to be locked down for it. right. Because this entitlement not only means allow some particular action, it also implcitly means if no other entitlement is present, don't show these other actions. From this point of view, I am not that sure about the rhn:require acl=not system_has_bootstrap_entitlement(); pieces -- the entitlements should add capabilities, not block them. I understand what you mean. Do you see a clean way how to solve that? There are some tabs in the UI that have no ACL at the moment, so they are always visible but they should not be visible for a bootstrap image. I'm not sure how to solve that without the not system_has_bootstrap_entitlement(); Thank you for your time. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On 01.08.2012 11:24, Jan Pazdziora wrote: maybe you can tell me what you think about it? it looks very cool. Do you have a stream of patches for master? That's nice to hear :) I'll send you patches as soon as I can. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: Atlas by Covenant ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
Hello Uwe - from the user-side this is a cool feature, and seeing it implemented and working would be a great enhancement of spacewalk. If there was an additional way of putting that 'pre-Image' onto a USB stick, to boot from it (with Manager/Spacewalk Details for registration) that would be even better! (We have to preregister MACs to get them to PXEboot, so a prestart without PXE (showing the MACs) would a big boon, thought only for me!?!) Just my 5 cents, Best -Jonathan On 08/01/2012 10:42 AM, Uwe Gansert wrote: Hi, during hackweek here at SUSE, I did a feature for bootstrapping new machines with Spacewalk/SUSE Manager. It works so far but I'd like to show it to you and ask if you are interested in the feature and what you think in general about it. I introduced the feature here: http://suse.gansert.net/?p=542 maybe you can tell me what you think about it? -- Jonathan Hoser, M.Sc. Institute of Bioinformatics and System Biology WWW: http://mips.helmholtz-muenchen.de Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
Hello Uwe, Really nice feature. It is a little bit like ubuntu MAAS, but now with spacewalk for configuring and managing the systems. I'm looking forward to see this code in the master repo. Thanks. Kind regards, Jasper Aikema Citeren Uwe Gansert u...@suse.de: Hi, during hackweek here at SUSE, I did a feature for bootstrapping new machines with Spacewalk/SUSE Manager. It works so far but I'd like to show it to you and ask if you are interested in the feature and what you think in general about it. I introduced the feature here: http://suse.gansert.net/?p=542 maybe you can tell me what you think about it? -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: No Man's Land by Covenant ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] Bootstrap image feature
On 01.08.2012 11:22, Jonathan Hoser wrote: from the user-side this is a cool feature, and seeing it implemented and working would be a great enhancement of spacewalk. thanks If there was an additional way of putting that 'pre-Image' onto a USB stick, to boot from it (with Manager/Spacewalk Details for registration) that would be even better! in theory that's possible but I'm not sure if I understand the sense in that. If you can not PXE boot the server, the complete Create Cobbler System Record button is useless and you can not do much with the machine in Spacewalk then - except for seeing the hardware. (We have to preregister MACs to get them to PXEboot, so a prestart without PXE (showing the MACs) would a big boon, thought only for me!?!) I'm not sure if I understand that scenario. You have to boot locally and then you can PXE boot later? Sounds weird but if that's the case, then yes, it would make sense to put the image on a USB stick. -- ciao, Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Home: http://www.suse.de/~ug - Blog: http://suse.gansert.net listening to: Flux by Covenant ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
