New Admin for ECS

Thank you!  This is what I was looking to confirm.

Jason, if we go with 2 namespaces, am I able to use the same replication group?

I am getting the Error 400200 (http: 409): Namespace conflict.  Namespace shares a common mapping with another namespace.

The only thing that I can see that is the same is the replication group.

Thank you,

Mike

Hi Mike,

Yes, it is quite common for multiple namespaces to utilize the same replication group.  This is both acceptable and normal provisioning within ECS.  What exactly are you doing that causes this error?

Thanks,

Ben

I am trying to make a second namespace: directconnect

I typed it in like that with no spaces and no caps.

I used the only replication group that we have and for admin user I put in root since it is the only admin user we have currently.

I also set it to be available during an outage which the other namespace has as well.

Maybe one of these other settings is causing the error?

Thank you,

Mike

You will need to create a new management user to assign as your namespace admin.  You cannot assign a management user (root) to more than one namespace.  In the user management page, just create a new management user and don't assign them to System Monitor or System Admin roles.  This will make a strict namespace administrator with no additional privileges on the ECS.

Ben

Thank you, that worked great!.

I am also trying to create an object user to work with Atmos REST protocol.  The atmos configuration shows that it needs a shared secret; however, when I go to create the object user it only has S3, Groups (SWIFT), and CAS listed under object access.  Where is Atmos?  For the Atmos Rest configuration I need Host Name / IP which should be the load balancer I believe, and Subtenant ID which I believe is the Bucket name, User ID and shared secret.  None of these appear to be optional.

Also, when creating a bucket, what is the difference between leaving bucket retention set to 0 and the box for Infinite?  Does 0 mean that it can later be deleted manually but infinite means that it can never be deleted?

SourceOne I believe would be the application that manages the retention, so I do not want ECS to be doing retention then.

Thank you for all of the help!

Hi,

I have learned that Infinite means that it can never be deleted.  Also I see that the retention may be changed later so if need be the time may be altered as needs dictate.

I still do not know where to find the password for ATMOS object users.  Would this not need one?  Or can it use the password from S3?

Since we are using SourceOne which does its own indexing, would I want to enable Metadata search on the bucket?

Thank you!

For Atmos, you would use the S3 secret key as your password.  If you want to create a bucket for that is to be used as a subtenant for Atmos operations, you can use the Atmos API or the ECS management REST API (head_type=atmos) to create a new bucket.  What Atmos SDK are you using?  I can help you with the method call to create the subtenant.

-Ben

Hi Ben,

I am looking at a document from EMC called EMC SourceOne Email Management 7.2 SP2 Administration Guide.  I am looking at page 76 where it shows the configuration for ViPR via ATMOS REST container; it is Figure 24 of the document.

My thought was to create the subtenant/bucket in ECS via the ECS web management console which I believe is the ECS management REST API.  Then in the configuration of SourceOne it would just need to have the information supplied for the configuration and then it should be able to communicate between the two products, I believe.  (Please keep in mind that I do not have the username nor the password for CLI to ECS as our resident did not provide that to us when his residency completed.  We are working on securing that, but not there yet.)

We are wanting to use Atmos REST versus the CAS because of the limitations on CAS in SourceOne and in ECS.  It is important to my business users to be able to have an index, and I believe that CAS does not allow for this in either product.

Thank you for all of your help on this.  It seems that ECS is not as difficult as I thought it to be.

Okay, so it's probably easiest to create your subtenant using the Atmos API.  You will need your object user name and S3 secret key to be able to do this.  Can you please take a look at this community post which explains how to use the Atmos API to generate a new subtenant.  There is a script in the post that you can download.  Substitute your credentials and endpoint into the script and give it a try.  Let me know if you have any issues.

Creating an Atmos subtenant in ECS

Ben

Thanks Ben for all of you help on this.

Since I do not have CLI access, I was able to open a support ticket and they were able to run the commands and we have Source One connected to ECS now.

Thanks again!

Mike