7 Replies Latest reply on Dec 14, 2005 2:47 AM by Greg Kullberg

    Sharing Depot Objects as Read Only

      Hi,

       

      Is there a way to share a Depot Group so that the various roles can see what packages, software etc, is available without giving them the ability to modify or delete the items?

       

      I want the Roles to be able to create and modify their own Depot packages, but not amend the shared items?

       

      Thanks.

        • 1. Re: Sharing Depot Objects as Read Only

          Currently the way access control works for shared objects is that whatever permisisons your role has, you have the same permissions on anything shared to you. So, if you're sharing to someone, be aware of what permissions they have and what you're sharing.

           

          Generally we set up workflow so that you share the job, not the original package or script. That way development has control over what gets deployed, and makes parameters available to the people doing the execution.

           

          It is a good idea to set up a shared folder and a backup folder, in case you're worried about someone messing with something you've shared.

           

          Sharing is eventually going to change in Config Manager. I'm not one who can elaborate on it right now, but I know in the future you'll have much more control over the objects you share and permissions people have on them.

          • 2. Re: Sharing Depot Objects as Read Only

            As an addendum, the sharing model is changing in BL's next major release, due out in (I believe) March or April next year. At that point, the permissions one gets on a shared object will be manageable on a per-object basis rather than a per-role basis.

             

            In the meantime, I would follow Greg's advice.

            • 3. Re: Sharing Depot Objects as Read Only

              Ok, thanks for the info.

              • 4. Re: Sharing Depot Objects as Read Only

                In the Lotus release next year, there is not a separate folder structure for shared objects (e.g. Depot and Shared Depot). Instead, folders and objects have access control lists (ACLs) that grant permissions to specific Roles on a per-object basis. "Sharing" an object would be done by granting a different role access to Read, Update and/or Delete an object or folder.

                • 5. Re: Sharing Depot Objects as Read Only

                   

                  Generally we set up workflow so that you share the

                  job, not the original package or script. That way

                  development has control over what gets deployed, and

                  makes parameters available to the people doing the

                  execution.

                   

                   

                  I've tried sharing the job, but the problem with this is that the output from each job is also shared, as you cannot change where the job output goes. So if one Solaris client installs Apache and runs a Patch Check Analysis, the output is shared with all Solaris clients sharing those jobs. This isn't going to be acceptable to most clients.

                   

                  Do you know if this will also be covered in the next release?

                   

                  Is there currently (6.3.2 or 6.3.3) a way around this without creating duplicate jobs for every package or script I want to share?

                   

                  Thanks.

                  • 6. Re: Sharing Depot Objects as Read Only

                    Hi Steve,

                     

                    I encounted similiar issue under : https://www.bladelogic.com/community/thread.jspa?threadID=860&tstart=0 which I ultimately raised a call against (9110). As one of the chaps on here has mentioned, there is a future release which is due out which addresses some of these functions.

                     

                    Frank

                    • 7. Re: Sharing Depot Objects as Read Only

                      If you're concerned about job run logs being seen by people of various roles, then you will want to create a different share for each role. Currently there is no way to control who sees job runs, as we assume if you share the job with a role then you also want to share the history of that job.