signing on LR node01
26 views
Skip to first unread message
joe hobson
Oct 10, 2012, 3:44:23 AM10/10/12
to learnin...@googlegroups.com
Yesterday I noticed that some of the paradata records being published to LR node01 by Brokers of Expertise were showing up with submitter of j...@navigationnorth.com, rather than Brokers of Expertise (example: http://goo.gl/2BEFQ). We haven't changed how Brokers publishes, other than setting up a Persona account and going through the steps on the node. I'm almost positive I did the same steps on sandbox as I did on node01, yet my records are correct on sandbox (signed by the Brokers app, not the node) and not on node01. I tried to compare the 2 oauth-key setups for my account but this page does not load: http://sandbox.learningregistry.org/apps/oauth-key-management
I don't want node01 signing on my behalf, but I can't see how to revoke the setup for my account so that the node won't keep signing my records. There are now records in the LR published by Brokers that appear to be submitted by j...@navigationnorth.com. This would be okay except for the fact that I just published about 1000 resources from National Museum of American History and they were supposed to be signed by Smithsonian (key was provided). As far as I know, I did the exact same setup and publish mechanisms on sandbox and node01, yet the node01 records are signed by the node and not Smithsonian. Anyone care to delete more records from LR?
any help is greatly appreciated. thanks. ... .joe
Jim Klo
Oct 10, 2012, 12:29:18 PM10/10/12
to <learningreg-dev@googlegroups.com>
Joe,
I'll take care of it… do you have an ID of at least one of the docs? I have a feeling prod is suffering from a misconfiguration as well.. I'll fix it at the same time.
- Jim
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac
Yesterday I noticed that some of the paradata records being published to LR node01 by Brokers of Expertise were showing up with submitter of j...@navigationnorth.com, rather than Brokers of Expertise (example: http://goo.gl/2BEFQ). We haven't changed how Brokers publishes, other than setting up a Persona account and going through the steps on the node. I'm almost positive I did the same steps on sandbox as I did on node01, yet my records are correct on sandbox (signed by the Brokers app, not the node) and not on node01. I tried to compare the 2 oauth-key setups for my account but this page does not load: http://sandbox.learningregistry.org/apps/oauth-key-managementI don't want node01 signing on my behalf, but I can't see how to revoke the setup for my account so that the node won't keep signing my records. There are now records in the LR published by Brokers that appear to be submitted by j...@navigationnorth.com. This would be okay except for the fact that I just published about 1000 resources from National Museum of American History and they were supposed to be signed by Smithsonian (key was provided). As far as I know, I did the exact same setup and publish mechanisms on sandbox and node01, yet the node01 records are signed by the node and not Smithsonian. Anyone care to delete more records from LR?any help is greatly appreciated. thanks. ... .joe
--
joe hobson
Oct 10, 2012, 12:34:40 PM10/10/12
to learnin...@googlegroups.com
Thanks Jim. Here's one of the docs I published last night: http://node01.public.learningregistry.net/harvest/getrecord?by_doc_ID=true&request_ID=d70851cb601140f39945e1660a4e5a49
I would say that if you're going to cleanup, you could delete anything with submitter: "j...@navigationnorth.com"
thanks. ... .joe
Steve Midgley
Oct 10, 2012, 1:16:44 PM10/10/12
to learnin...@googlegroups.com
And just as a reminder, the deletion should leave a "gravestone" record per our previous agreement on deleted if the prod nodes have fulfilled any replication obligations with other nodes out there (not sure what logs exist to tell if the errant records have "left the barn" yet..).
Steve
--
Jim Klo
Oct 10, 2012, 1:35:35 PM10/10/12
to <learningreg-dev@googlegroups.com>
CouchDB leaves a gravestone by default, no real way to get around that.
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac
--
Steve Midgley
Oct 10, 2012, 1:43:50 PM10/10/12
to learnin...@googlegroups.com
I was referring to our explicity "anti-replication" gravestone, but maybe they are the same? I think we talked about deletion, not being a couch deletion but a changing of the envelope contents to something very minimal just indicating "do not replicate." This prevents other nodes from replicating back to us..
Is that unnecessary b/c couch does the same thing? I'd worry that on data base compression we'd lose those delete gravestones?
Steve
Jim Klo
Oct 10, 2012, 1:48:15 PM10/10/12
to <learningreg-dev@googlegroups.com>
We have a do_not_distribute flag, but it's not supported by any of the harvesting interfaces, only distribution.
There's no way to remove the couchdb gravestone, without replicating to a new DB or purging the records. Compaction will get rid of history, but not the gravestone.
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac
--
Steve Midgley
Oct 10, 2012, 1:52:14 PM10/10/12
to learnin...@googlegroups.com
So what is the correct LR policy? Just delete manually inside Couch? Or set a do_not_distribute flag on any record that is to be deleted (and delete any all content in the envelope as needed for local compliance to the delete intention)?
Steve
Jim Klo
Oct 10, 2012, 2:05:43 PM10/10/12
to <learningreg-dev@googlegroups.com>
For the time being, better or worse, I'm deleting from CouchDB since do_not_distribute isn't honored by anything other than distribute at this time AFAIK.
FWIW, the do_not_distribute could be honored by harvest via updating our CouchDB views to exclude any doc with that flag. However that will require a rev.
Jim Klo
Senior Software Engineer
Center for Software Engineering
SRI International
t. @nsomnac
Reply all
Reply to author
Forward
0 new messages