We've been using the duracloud rest api to integrate with islandora.
We can get content and properties and list services etc. but when
trying to deploy the bitintegrity service we are getting a 403
forbidden. We are trying this as a limited user (just a normal User
not Administrator or owner).
To start a service, you will need to make the call with a user that has
either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was
simplifying the interaction with DuraCloud for those with role USER, and
that resulted in a variety of changes, including the automation of several
services, as well as the adjusting of user privileges. Unfortunately, it
looks like we missed updating that bit of documentation in the process.
There is a bit more work left to clean up the security settings (noted
here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted the
need to update the documentation to bring it up to date with the code.
Sorry for the confusion. Let us know if you run into any other issues as
you work on the integration.
On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
> We've been using the duracloud rest api to integrate with islandora.
> We can get content and properties and list services etc. but when
> trying to deploy the bitintegrity service we are getting a 403
> forbidden. We are trying this as a limited user (just a normal User
> not Administrator or owner).
> I can't see a way to deploy a service when logged in to duracloud as a
> non admin user either so I maybe missing something?
> Thanks,
> Paul
> --
> You received this message because you are subscribed to the Google Groups
> "DuraCloud Dev" group.
> To post to this group, send email to duracloud-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> duracloud-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/duracloud-dev?hl=en.
Yeah, it's a job and a half just keeping documentation up to date.
What would work well for us would be users with the USER role being able to
run services for spaces that they have read/write access on. Or similarly
it would work if we could limit an Adminstrator type user to a certain
space/spaces. We have many Drupal/Islandora instances pointed at one
Fedora and in some cases the Fedora items each Islandora instance can
access is limited. We would like to limit what each Islandora instance can
access in Duracloud as well (which we can do with different users and
spaces) but also allow their Islandora instance to deploy services (really
only the integrity related ones) from Duracloud for their space.
I'm guessing though that for now we will need different Duracloud instances
for this type of behaviour?
I also think we can mimic some of this behaviour with someone managing the
services and running/scheduling the services on behalf of each site but if
each site could manage their own it would be better for our use case. Some
of my assumptions maybe incorrect (let me know if they are) as we are
really just getting into the details.
On Thu, Jul 5, 2012 at 5:04 PM, Bill Branan <bbra...@duraspace.org> wrote:
> Hi Paul,
> To start a service, you will need to make the call with a user that has
> either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was
> simplifying the interaction with DuraCloud for those with role USER, and
> that resulted in a variety of changes, including the automation of several
> services, as well as the adjusting of user privileges. Unfortunately, it
> looks like we missed updating that bit of documentation in the process.
> There is a bit more work left to clean up the security settings (noted
> here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted
> the need to update the documentation to bring it up to date with the code.
> Sorry for the confusion. Let us know if you run into any other issues as
> you work on the integration.
> Bill
> On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
>> We've been using the duracloud rest api to integrate with islandora.
>> We can get content and properties and list services etc. but when
>> trying to deploy the bitintegrity service we are getting a 403
>> forbidden. We are trying this as a limited user (just a normal User
>> not Administrator or owner).
>> I can't see a way to deploy a service when logged in to duracloud as a
>> non admin user either so I maybe missing something?
>> Thanks,
>> Paul
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DuraCloud Dev" group.
>> To post to this group, send email to duracloud-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> duracloud-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/duracloud-dev?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DuraCloud Dev" group.
> To post to this group, send email to duracloud-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> duracloud-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/duracloud-dev?hl=en.
What we found to be the case for DuraCloud is that our users really prefer
for services like bit integrity to simply be managed for them. Everybody
liked the idea of frequent bit integrity checking, but very few were
interested in managing the details. That is what led us to the development
of the Executor piece of the new-to-2.0.0 DuraBoss application. If you're
not familiar with it, the Executor lets you manage certain services at a
higher level. In particular, the services that the Executor deals with at
the moment are bit integrity and media streaming, but the plan is to
include many of the other services as well. For bit integrity, you can make
one call to the Executor specifying when it should start the next round of
bit integrity checks and how often after that it should repeat the cycle.
The Executor will then handle running the Bit Integrity Service for you
over all of the spaces in a DuraCloud account. When starting a DuraCloud
instance, we now configure the Executor to run bit integrity checks
starting on a Saturday morning about once a month. The "Last Health Check"
row in the space details area of the UI shows when the last successful bit
integrity check was run over a given space.
Clearly you weren't asking about the Executor piece, but it does do rather
a lot of work for you. You now get a bit integrity check over each space
every 4 weeks without having to do anything. If you'd like to change the
schedule of the bit integrity runs, you can do so by making calls as noted
here:
https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+REST+API#Du... .
If you'd like to continue running the Bit Integrity Service on your own,
which you're welcome to do, you will need to do so with an ADMIN or OWNER
role user, as there's not currently a way for those with USER role to kick
off services. One of the reasons for that is that we currently only allow a
single copy of any service to be running at a time. So even if we did open
up access to allow those with USER role to run services, you'd need to put
limits in place so that not more than one user would try to run the service
while it is running for another user. We also decided that in the
multi-tenant case, like you're describing, those with USER role might see
information in the service configuration that they should not see otherwise
(like a space name they don't have access to, and the number of items in
that space). Keeping the running of services as an administrative task
seemed like the best solution to these concerns.
I'll be interested to know what direction you decide to go on this. Feel
free to ask other questions as they come up.
On Fri, Jul 6, 2012 at 8:54 AM, Paul Pound <ppo...@upei.ca> wrote:
> Hi Bill,
> Thanks for the quick response.
> Yeah, it's a job and a half just keeping documentation up to date.
> What would work well for us would be users with the USER role being able
> to run services for spaces that they have read/write access on. Or
> similarly it would work if we could limit an Adminstrator type user to a
> certain space/spaces. We have many Drupal/Islandora instances pointed at
> one Fedora and in some cases the Fedora items each Islandora instance can
> access is limited. We would like to limit what each Islandora instance can
> access in Duracloud as well (which we can do with different users and
> spaces) but also allow their Islandora instance to deploy services (really
> only the integrity related ones) from Duracloud for their space.
> I'm guessing though that for now we will need different Duracloud
> instances for this type of behaviour?
> I also think we can mimic some of this behaviour with someone managing the
> services and running/scheduling the services on behalf of each site but if
> each site could manage their own it would be better for our use case. Some
> of my assumptions maybe incorrect (let me know if they are) as we are
> really just getting into the details.
> Thanks again,
> Paul
> On Thu, Jul 5, 2012 at 5:04 PM, Bill Branan <bbra...@duraspace.org> wrote:
>> Hi Paul,
>> To start a service, you will need to make the call with a user that has
>> either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was
>> simplifying the interaction with DuraCloud for those with role USER, and
>> that resulted in a variety of changes, including the automation of several
>> services, as well as the adjusting of user privileges. Unfortunately, it
>> looks like we missed updating that bit of documentation in the process.
>> There is a bit more work left to clean up the security settings (noted
>> here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted
>> the need to update the documentation to bring it up to date with the code.
>> Sorry for the confusion. Let us know if you run into any other issues as
>> you work on the integration.
>> Bill
>> On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
>>> We've been using the duracloud rest api to integrate with islandora.
>>> We can get content and properties and list services etc. but when
>>> trying to deploy the bitintegrity service we are getting a 403
>>> forbidden. We are trying this as a limited user (just a normal User
>>> not Administrator or owner).
>>> I can't see a way to deploy a service when logged in to duracloud as a
>>> non admin user either so I maybe missing something?
>>> Thanks,
>>> Paul
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DuraCloud Dev" group.
>>> To post to this group, send email to duracloud-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> duracloud-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/duracloud-dev?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DuraCloud Dev" group.
>> To post to this group, send email to duracloud-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> duracloud-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/duracloud-dev?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DuraCloud Dev" group.
> To post to this group, send email to duracloud-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> duracloud-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/duracloud-dev?hl=en.
Thanks for the info Bill. The executor maybe all we need.
One of the reasons I was looking at the services is that it looked like we
could run it as a non privileged user (i was incorrect in that assumption)
and it looked to me like the executor stuff required a privileged user.
But i can see the health check report as a non privileged user in the
Duracloud gui so can i get to it using the api? If we can access that as
just a USER I think that would satisfy our needs for now.
I'm looking at this page again
https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+Security and it
looks like the executor and reports require admin privileges. I know this
may not be accurate. All the non privileged user would need is access to
the latest report via the api, they wouldn't need to schedule it or run it.
Below is a quick overview of what we have so far and what we would like to
do:
We create a space in Duracloud and create a USER with read and write access
to that space (DGI or UPEI would set this up). We then create a store in
Cloudsync with that user info and then provide that Cloudsync store uri to
Islandora, an admin would update Islandora config with the uri. Using the
Cloudsync api we can create tasks and sets based on fedora objects and
collections from within Islandora. We can also run the tasks from within
Islandora. The user information from that Cloudsync store can also be used
to connect to Duracloud to compare checksums and hopefully get the executor
health status reports.
I agree with the users wanting stuff managed for them, we are trying to
make it as simple as possible for islandora users, Ideally they would never
have to actually login to Cloudsync or Duracloud but still get all the
benefits by configuring Islandora to use these services.
On Fri, Jul 6, 2012 at 11:45 AM, Bill Branan <bbra...@duraspace.org> wrote:
> Hi Paul,
> What we found to be the case for DuraCloud is that our users really prefer
> for services like bit integrity to simply be managed for them. Everybody
> liked the idea of frequent bit integrity checking, but very few were
> interested in managing the details. That is what led us to the development
> of the Executor piece of the new-to-2.0.0 DuraBoss application. If you're
> not familiar with it, the Executor lets you manage certain services at a
> higher level. In particular, the services that the Executor deals with at
> the moment are bit integrity and media streaming, but the plan is to
> include many of the other services as well. For bit integrity, you can make
> one call to the Executor specifying when it should start the next round of
> bit integrity checks and how often after that it should repeat the cycle.
> The Executor will then handle running the Bit Integrity Service for you
> over all of the spaces in a DuraCloud account. When starting a DuraCloud
> instance, we now configure the Executor to run bit integrity checks
> starting on a Saturday morning about once a month. The "Last Health Check"
> row in the space details area of the UI shows when the last successful bit
> integrity check was run over a given space.
> Clearly you weren't asking about the Executor piece, but it does do rather
> a lot of work for you. You now get a bit integrity check over each space
> every 4 weeks without having to do anything. If you'd like to change the
> schedule of the bit integrity runs, you can do so by making calls as noted
> here:
> https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+REST+API#Du... > .
> If you'd like to continue running the Bit Integrity Service on your own,
> which you're welcome to do, you will need to do so with an ADMIN or OWNER
> role user, as there's not currently a way for those with USER role to kick
> off services. One of the reasons for that is that we currently only allow a
> single copy of any service to be running at a time. So even if we did open
> up access to allow those with USER role to run services, you'd need to put
> limits in place so that not more than one user would try to run the service
> while it is running for another user. We also decided that in the
> multi-tenant case, like you're describing, those with USER role might see
> information in the service configuration that they should not see otherwise
> (like a space name they don't have access to, and the number of items in
> that space). Keeping the running of services as an administrative task
> seemed like the best solution to these concerns.
> I'll be interested to know what direction you decide to go on this. Feel
> free to ask other questions as they come up.
> Bill
> On Fri, Jul 6, 2012 at 8:54 AM, Paul Pound <ppo...@upei.ca> wrote:
>> Hi Bill,
>> Thanks for the quick response.
>> Yeah, it's a job and a half just keeping documentation up to date.
>> What would work well for us would be users with the USER role being able
>> to run services for spaces that they have read/write access on. Or
>> similarly it would work if we could limit an Adminstrator type user to a
>> certain space/spaces. We have many Drupal/Islandora instances pointed at
>> one Fedora and in some cases the Fedora items each Islandora instance can
>> access is limited. We would like to limit what each Islandora instance can
>> access in Duracloud as well (which we can do with different users and
>> spaces) but also allow their Islandora instance to deploy services (really
>> only the integrity related ones) from Duracloud for their space.
>> I'm guessing though that for now we will need different Duracloud
>> instances for this type of behaviour?
>> I also think we can mimic some of this behaviour with someone managing
>> the services and running/scheduling the services on behalf of each site but
>> if each site could manage their own it would be better for our use case.
>> Some of my assumptions maybe incorrect (let me know if they are) as we are
>> really just getting into the details.
>> Thanks again,
>> Paul
>> On Thu, Jul 5, 2012 at 5:04 PM, Bill Branan <bbra...@duraspace.org>wrote:
>>> Hi Paul,
>>> To start a service, you will need to make the call with a user that has
>>> either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was
>>> simplifying the interaction with DuraCloud for those with role USER, and
>>> that resulted in a variety of changes, including the automation of several
>>> services, as well as the adjusting of user privileges. Unfortunately, it
>>> looks like we missed updating that bit of documentation in the process.
>>> There is a bit more work left to clean up the security settings (noted
>>> here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted
>>> the need to update the documentation to bring it up to date with the code.
>>> Sorry for the confusion. Let us know if you run into any other issues as
>>> you work on the integration.
>>> Bill
>>> On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
>>>> We've been using the duracloud rest api to integrate with islandora.
>>>> We can get content and properties and list services etc. but when
>>>> trying to deploy the bitintegrity service we are getting a 403
>>>> forbidden. We are trying this as a limited user (just a normal User
>>>> not Administrator or owner).
>>>> I can't see a way to deploy a service when logged in to duracloud as a
>>>> non admin user either so I maybe missing something?
>>>> Thanks,
>>>> Paul
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "DuraCloud Dev" group.
>>>> To post to this group, send email to duracloud-dev@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> duracloud-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/duracloud-dev?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DuraCloud Dev" group.
>>> To post to this group, send email to duracloud-dev@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> duracloud-dev+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/duracloud-dev?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DuraCloud Dev" group.
>> To post to this group, send email to duracloud-dev@googlegroups.com.
>> To unsubscribe from this group, send email to
>> duracloud-dev+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/duracloud-dev?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DuraCloud Dev" group.
> To post to this group, send email to duracloud-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> duracloud-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/duracloud-dev?hl=en.
Your plan for integration with DuraCloud via CloudSync sounds like a good
one. Regarding getting access to reports, there are a few ways that could
be done. The bit integrity reports are stored in the x-service-out space,
this is where service reports always go, regardless of whether they are
managed by the executor or the service is run independently. That space is
not configured by default to be readable by anyone but administrators. To
show the reports to the user in the DuraCloud UI we actually use another
set of access credentials rather than those of the logged in user.
A few possible ways for you to provide users with access to reports:
1. Set access controls in DuraCloud to open up access to the x-service-out
space. This would give all users access to all reports for everyone, which
may not be desirable, but it would be simple.
2. Set up a CloudSync store with acces to x-service-out, and have it pull
the reports into Fedora. You'd then be able to use Fedora access controls
to set which users can see which reports.
3. Set up a batch job that can use the DuraCloud API (with admin
credentials) to copy reports from x-service-out into a space which the user
does have access to see them. You would then be able to use the CloudSync
integration to retrieve the reports for the user.
As a note, the storage reports (which provide the data for the History
charts) are stored in the x-duracloud-admin space (they are created by the
Reporter portion of DuraBoss, not a service). You could use the same
strategy as for bit integrity reports if you want users to be able to see
the storage reports.
On Fri, Jul 6, 2012 at 4:20 PM, Paul Pound <ppo...@upei.ca> wrote:
> Thanks for the info Bill. The executor maybe all we need.
> One of the reasons I was looking at the services is that it looked like we
> could run it as a non privileged user (i was incorrect in that assumption)
> and it looked to me like the executor stuff required a privileged user.
> But i can see the health check report as a non privileged user in the
> Duracloud gui so can i get to it using the api? If we can access that as
> just a USER I think that would satisfy our needs for now.
> I'm looking at this page again
> https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+Security and it
> looks like the executor and reports require admin privileges. I know this
> may not be accurate. All the non privileged user would need is access to
> the latest report via the api, they wouldn't need to schedule it or run it.
> Below is a quick overview of what we have so far and what we would like to
> do:
> We create a space in Duracloud and create a USER with read and write
> access to that space (DGI or UPEI would set this up). We then create a
> store in Cloudsync with that user info and then provide that Cloudsync
> store uri to Islandora, an admin would update Islandora config with the
> uri. Using the Cloudsync api we can create tasks and sets based on fedora
> objects and collections from within Islandora. We can also run the tasks
> from within Islandora. The user information from that Cloudsync store can
> also be used to connect to Duracloud to compare checksums and hopefully get
> the executor health status reports.
> I agree with the users wanting stuff managed for them, we are trying to
> make it as simple as possible for islandora users, Ideally they would never
> have to actually login to Cloudsync or Duracloud but still get all the
> benefits by configuring Islandora to use these services.
> Thanks again for your help,
> Paul
> On Fri, Jul 6, 2012 at 11:45 AM, Bill Branan <bbra...@duraspace.org>wrote:
>> Hi Paul,
>> What we found to be the case for DuraCloud is that our users really
>> prefer for services like bit integrity to simply be managed for them.
>> Everybody liked the idea of frequent bit integrity checking, but very few
>> were interested in managing the details. That is what led us to the
>> development of the Executor piece of the new-to-2.0.0 DuraBoss application.
>> If you're not familiar with it, the Executor lets you manage certain
>> services at a higher level. In particular, the services that the Executor
>> deals with at the moment are bit integrity and media streaming, but the
>> plan is to include many of the other services as well. For bit integrity,
>> you can make one call to the Executor specifying when it should start the
>> next round of bit integrity checks and how often after that it should
>> repeat the cycle. The Executor will then handle running the Bit Integrity
>> Service for you over all of the spaces in a DuraCloud account. When
>> starting a DuraCloud instance, we now configure the Executor to run bit
>> integrity checks starting on a Saturday morning about once a month. The
>> "Last Health Check" row in the space details area of the UI shows when the
>> last successful bit integrity check was run over a given space.
>> Clearly you weren't asking about the Executor piece, but it does do
>> rather a lot of work for you. You now get a bit integrity check over each
>> space every 4 weeks without having to do anything. If you'd like to change
>> the schedule of the bit integrity runs, you can do so by making calls as
>> noted here:
>> https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+REST+API#Du... >> .
>> If you'd like to continue running the Bit Integrity Service on your own,
>> which you're welcome to do, you will need to do so with an ADMIN or OWNER
>> role user, as there's not currently a way for those with USER role to kick
>> off services. One of the reasons for that is that we currently only allow a
>> single copy of any service to be running at a time. So even if we did open
>> up access to allow those with USER role to run services, you'd need to put
>> limits in place so that not more than one user would try to run the service
>> while it is running for another user. We also decided that in the
>> multi-tenant case, like you're describing, those with USER role might see
>> information in the service configuration that they should not see otherwise
>> (like a space name they don't have access to, and the number of items in
>> that space). Keeping the running of services as an administrative task
>> seemed like the best solution to these concerns.
>> I'll be interested to know what direction you decide to go on this. Feel
>> free to ask other questions as they come up.
>> Bill
>> On Fri, Jul 6, 2012 at 8:54 AM, Paul Pound <ppo...@upei.ca> wrote:
>>> Hi Bill,
>>> Thanks for the quick response.
>>> Yeah, it's a job and a half just keeping documentation up to date.
>>> What would work well for us would be users with the USER role being able
>>> to run services for spaces that they have read/write access on. Or
>>> similarly it would work if we could limit an Adminstrator type user to a
>>> certain space/spaces. We have many Drupal/Islandora instances pointed at
>>> one Fedora and in some cases the Fedora items each Islandora instance can
>>> access is limited. We would like to limit what each Islandora instance can
>>> access in Duracloud as well (which we can do with different users and
>>> spaces) but also allow their Islandora instance to deploy services (really
>>> only the integrity related ones) from Duracloud for their space.
>>> I'm guessing though that for now we will need different Duracloud
>>> instances for this type of behaviour?
>>> I also think we can mimic some of this behaviour with someone managing
>>> the services and running/scheduling the services on behalf of each site but
>>> if each site could manage their own it would be better for our use case.
>>> Some of my assumptions maybe incorrect (let me know if they are) as we are
>>> really just getting into the details.
>>> Thanks again,
>>> Paul
>>> On Thu, Jul 5, 2012 at 5:04 PM, Bill Branan <bbra...@duraspace.org>wrote:
>>>> Hi Paul,
>>>> To start a service, you will need to make the call with a user that has
>>>> either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release was
>>>> simplifying the interaction with DuraCloud for those with role USER, and
>>>> that resulted in a variety of changes, including the automation of several
>>>> services, as well as the adjusting of user privileges. Unfortunately, it
>>>> looks like we missed updating that bit of documentation in the process.
>>>> There is a bit more work left to clean up the security settings (noted
>>>> here: https://jira.duraspace.org/browse/DURACLOUD-668), and I've noted
>>>> the need to update the documentation to bring it up to date with the code.
>>>> Sorry for the confusion. Let us know if you run into any other issues
>>>> as you work on the integration.
>>>> Bill
>>>> On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
>>>>> We've been using the duracloud rest api to integrate with islandora.
>>>>> We can get content and properties and list services etc. but when
>>>>> trying to deploy the bitintegrity service we are getting a 403
>>>>> forbidden. We are trying this as a limited user (just a normal User
>>>>> not Administrator or owner).
On Sat, Jul 7, 2012 at 4:13 PM, Bill Branan <bbra...@duraspace.org> wrote:
> Hi Paul,
> Your plan for integration with DuraCloud via CloudSync sounds like a good
> one. Regarding getting access to reports, there are a few ways that could
> be done. The bit integrity reports are stored in the x-service-out space,
> this is where service reports always go, regardless of whether they are
> managed by the executor or the service is run independently. That space is
> not configured by default to be readable by anyone but administrators. To
> show the reports to the user in the DuraCloud UI we actually use another
> set of access credentials rather than those of the logged in user.
> A few possible ways for you to provide users with access to reports:
> 1. Set access controls in DuraCloud to open up access to the x-service-out
> space. This would give all users access to all reports for everyone, which
> may not be desirable, but it would be simple.
> 2. Set up a CloudSync store with acces to x-service-out, and have it pull
> the reports into Fedora. You'd then be able to use Fedora access controls
> to set which users can see which reports.
> 3. Set up a batch job that can use the DuraCloud API (with admin
> credentials) to copy reports from x-service-out into a space which the user
> does have access to see them. You would then be able to use the CloudSync
> integration to retrieve the reports for the user.
> As a note, the storage reports (which provide the data for the History
> charts) are stored in the x-duracloud-admin space (they are created by the
> Reporter portion of DuraBoss, not a service). You could use the same
> strategy as for bit integrity reports if you want users to be able to see
> the storage reports.
> Hopefully this helps.
> Bill
> On Fri, Jul 6, 2012 at 4:20 PM, Paul Pound <ppo...@upei.ca> wrote:
>> Thanks for the info Bill. The executor maybe all we need.
>> One of the reasons I was looking at the services is that it looked like
>> we could run it as a non privileged user (i was incorrect in that
>> assumption) and it looked to me like the executor stuff required a
>> privileged user. But i can see the health check report as a
>> non privileged user in the Duracloud gui so can i get to it using the api?
>> If we can access that as just a USER I think that would satisfy our needs
>> for now.
>> I'm looking at this page again
>> https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+Security and
>> it looks like the executor and reports require admin privileges. I know
>> this may not be accurate. All the non privileged user would need is access
>> to the latest report via the api, they wouldn't need to schedule it or run
>> it.
>> Below is a quick overview of what we have so far and what we would like
>> to do:
>> We create a space in Duracloud and create a USER with read and write
>> access to that space (DGI or UPEI would set this up). We then create a
>> store in Cloudsync with that user info and then provide that Cloudsync
>> store uri to Islandora, an admin would update Islandora config with the
>> uri. Using the Cloudsync api we can create tasks and sets based on fedora
>> objects and collections from within Islandora. We can also run the tasks
>> from within Islandora. The user information from that Cloudsync store can
>> also be used to connect to Duracloud to compare checksums and hopefully get
>> the executor health status reports.
>> I agree with the users wanting stuff managed for them, we are trying to
>> make it as simple as possible for islandora users, Ideally they would never
>> have to actually login to Cloudsync or Duracloud but still get all the
>> benefits by configuring Islandora to use these services.
>> Thanks again for your help,
>> Paul
>> On Fri, Jul 6, 2012 at 11:45 AM, Bill Branan <bbra...@duraspace.org>wrote:
>>> Hi Paul,
>>> What we found to be the case for DuraCloud is that our users really
>>> prefer for services like bit integrity to simply be managed for them.
>>> Everybody liked the idea of frequent bit integrity checking, but very few
>>> were interested in managing the details. That is what led us to the
>>> development of the Executor piece of the new-to-2.0.0 DuraBoss application.
>>> If you're not familiar with it, the Executor lets you manage certain
>>> services at a higher level. In particular, the services that the Executor
>>> deals with at the moment are bit integrity and media streaming, but the
>>> plan is to include many of the other services as well. For bit integrity,
>>> you can make one call to the Executor specifying when it should start the
>>> next round of bit integrity checks and how often after that it should
>>> repeat the cycle. The Executor will then handle running the Bit Integrity
>>> Service for you over all of the spaces in a DuraCloud account. When
>>> starting a DuraCloud instance, we now configure the Executor to run bit
>>> integrity checks starting on a Saturday morning about once a month. The
>>> "Last Health Check" row in the space details area of the UI shows when the
>>> last successful bit integrity check was run over a given space.
>>> Clearly you weren't asking about the Executor piece, but it does do
>>> rather a lot of work for you. You now get a bit integrity check over each
>>> space every 4 weeks without having to do anything. If you'd like to change
>>> the schedule of the bit integrity runs, you can do so by making calls as
>>> noted here:
>>> https://wiki.duraspace.org/display/DURACLOUDDOC/DuraCloud+REST+API#Du... >>> .
>>> If you'd like to continue running the Bit Integrity Service on your own,
>>> which you're welcome to do, you will need to do so with an ADMIN or OWNER
>>> role user, as there's not currently a way for those with USER role to kick
>>> off services. One of the reasons for that is that we currently only allow a
>>> single copy of any service to be running at a time. So even if we did open
>>> up access to allow those with USER role to run services, you'd need to put
>>> limits in place so that not more than one user would try to run the service
>>> while it is running for another user. We also decided that in the
>>> multi-tenant case, like you're describing, those with USER role might see
>>> information in the service configuration that they should not see otherwise
>>> (like a space name they don't have access to, and the number of items in
>>> that space). Keeping the running of services as an administrative task
>>> seemed like the best solution to these concerns.
>>> I'll be interested to know what direction you decide to go on this. Feel
>>> free to ask other questions as they come up.
>>> Bill
>>> On Fri, Jul 6, 2012 at 8:54 AM, Paul Pound <ppo...@upei.ca> wrote:
>>>> Hi Bill,
>>>> Thanks for the quick response.
>>>> Yeah, it's a job and a half just keeping documentation up to date.
>>>> What would work well for us would be users with the USER role being
>>>> able to run services for spaces that they have read/write access on. Or
>>>> similarly it would work if we could limit an Adminstrator type user to a
>>>> certain space/spaces. We have many Drupal/Islandora instances pointed at
>>>> one Fedora and in some cases the Fedora items each Islandora instance can
>>>> access is limited. We would like to limit what each Islandora instance can
>>>> access in Duracloud as well (which we can do with different users and
>>>> spaces) but also allow their Islandora instance to deploy services (really
>>>> only the integrity related ones) from Duracloud for their space.
>>>> I'm guessing though that for now we will need different Duracloud
>>>> instances for this type of behaviour?
>>>> I also think we can mimic some of this behaviour with someone managing
>>>> the services and running/scheduling the services on behalf of each site but
>>>> if each site could manage their own it would be better for our use case.
>>>> Some of my assumptions maybe incorrect (let me know if they are) as we are
>>>> really just getting into the details.
>>>> Thanks again,
>>>> Paul
>>>> On Thu, Jul 5, 2012 at 5:04 PM, Bill Branan <bbra...@duraspace.org>wrote:
>>>>> Hi Paul,
>>>>> To start a service, you will need to make the call with a user that
>>>>> has either the ADMIN or OWNER role. Part of the goal for the 2.0.0 release
>>>>> was simplifying the interaction with DuraCloud for those with role USER,
>>>>> and that resulted in a variety of changes, including the automation of
>>>>> several services, as well as the adjusting of user privileges.
>>>>> Unfortunately, it looks like we missed updating that bit of documentation
>>>>> in the process. There is a bit more work left to clean up the security
>>>>> settings (noted here: https://jira.duraspace.org/browse/DURACLOUD-668),
>>>>> and I've noted the need to update the documentation to bring it up to date
>>>>> with the code.
>>>>> Sorry for the confusion. Let us know if you run into any other issues
>>>>> as you work on the integration.
>>>>> Bill
>>>>> On Thu, Jul 5, 2012 at 3:49 PM, Paul Pound <ppo...@upei.ca> wrote:
>>>>>> We've been using the duracloud rest api to integrate with islandora.
>>>>>> We can get content and properties and list services etc. but when
>>>>>> trying to deploy the bitintegrity service we are getting a 403
>>>>>> forbidden. We are trying this as a limited user (just a normal User
>>>>>> not Administrator or owner).
