[Planetlab-devel] sfa database

[Tony Mack]

Yes, this has been an issue for anyone who has multiple keys. It would be nice if we could mark key as the sfa key. Thierry, can you think of a good way to do this given our current tagging system?

Tony

----- Original Message -----
From: "Thierry Parmentelat" <thierry.parmentelat at inria.fr>
To: "PlanetLab Development" <devel at planet-lab.org>
Sent: Friday, December 2, 2011 10:55:02 AM
Subject: Re: [Planetlab-devel] sfa database

good question; 
although the PLC db may have several such keys, it turns out that in the process of generating the user certificate we need to pick one; and that's the one that would be relevant to sfa. Honestly I have no idea how inconvenient the current code is for people who really use mutiple keys routinely.


On Dec 2, 2011, at 4:41 PM, Sarah Edwards wrote:

> I'll bite.
> 
> Why _one_ ssh key?
> 
> On Dec 2, 2011, at 10:32 AM, Thierry Parmentelat wrote:
> 
>> So nobody really has anything to say on this one ?
>> meanwhile I think I've reached the conclusion, although this is still fuzzy, that keeping track of one ssh key could be needed as well..
>> 
>> On Nov 30, 2011, at 6:40 PM, Thierry Parmentelat wrote:
>> 
>>> Hi folks
>>> 
>>> As you might know I've spent some time recently, trying to refactor the registry manager in order to make it more generic 
>>> 
>>> In the process I came across a rather painful issue, that I thought could use a bit of brainstorming here
>>> 
>>> In essence, I guess I would argue that the SFA db should keep track of at least some of the inter-object relationships
>>> In particular for the user x authority at the very least
>>> 
>>> Right now SFA deeply relies on myplc to retrieve this information; I am referring to 'fill_record_info'; which digs into the myplc database to retrieve the object, its relationships, messes with hrns in the process (in addition this is utterly unefficient); all this is essentially a back and forth between sfa data and plc data to reconstruct relationships.
>>> 
>>> In order to illustrate my point, imagine a testbed that's entirely dumb, in that it has a rustic account management system (you'd be surprised how common this is; localized testbeds commonly just have a LDAP server somewhere to manage accounts and that's about it)
>>> In such a case fill_record_info really can't do much; at first I thought this would only have cosmetic impact, and would only affect sfi show <>
>>> But when I got to trying it out, I realized that because the requestor/authority relationship could not be properly reconstructed, no right would be granted to the requestor and thus nobody could do anything on the testbed
>>> 
>>> So, because this particular relationship is so crucial to the internals of SFA, I would suggest that this info becomes duplicated in the SFA db as well
>>> Just checking if that would go against any fundamental design decision that I would have missed, otherwise if that's fine with everyone I would add this to my list (not in the near future, but on a bit longer term)
>>> 
>>> [[I would in a first implementation just add a very generic obj1 x obj2 x relation_type table so that more relationships can be kept track of locally if need be]]
>>> 
>>> -- Thierry
>>> 
>>> 
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.planet-lab.org
>>> https://lists.planet-lab.org/mailman/listinfo/devel
>> 
>> 
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
> 
> *******************************************************************************
> Sarah Edwards
> Network Research
> Raytheon BBN Technologies
> Cambridge, MA
> 
> phone:    (617) 873-2329
> fax:          (617) 873-6091
> email:      sedwards at bbn.com
> 
> 
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel


_______________________________________________
Devel mailing list
Devel at lists.planet-lab.org
https://lists.planet-lab.org/mailman/listinfo/devel