[Planetlab-devel] sfa database
tmack at cs.princeton.edu
Fri Dec 2 14:51:28 EST 2011
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?
----- 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
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
>> Devel mailing list
>> Devel at lists.planet-lab.org
> 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
Devel mailing list
Devel at lists.planet-lab.org
More information about the Devel