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
