S3 store using Dell Isilon OneFS

1,521 views
Skip to first unread message

Deirdre Kirmis

unread,
Apr 20, 2021, 3:03:01 AM4/20/21
to dataverse...@googlegroups.com

Hi All … wondering if anyone has successfully configured Dell Isilon NAS (with PowerScale OneFS for native S3)  as a store in Dataverse?  If so, what parameters did you use for the various JVM options required for DV?

Any tips are greatly appreciated!

 

Thanks!

Night Owl

 

Deirdre Kirmis

unread,
May 5, 2021, 11:28:54 AM5/5/21
to dataverse...@googlegroups.com

Hi all … just an update on this and request for suggestions from others who have configured non-aws S3 for Dataverse stores.  For this particular storage, I am able to successfully list and copy files to it using AWS CLI and Rclone (although in both cases I have to use a flag to ignore SSL check. (ie: --no-verify-ssl)).

 

There is a custom DNS entry pointing to the store, using a specific port, so In the rclone config, I am just specifying the endpoint URL as https://<endpoint>:<port> as well as the access ID and access key.

In the AWS config I just have the access ID and access key/secret key (no region is necessary). I was given a path to the bucket, but I don’t seem to need it to access the store (it doesn’t work if I use it).

 

For AWS, I can use the command “aws --endpoint-url https://<endpoint>:<port> s3 cp <filename> s3://<bucketname>  --no-verify-ssl --profile <profilename>”  and I can successfully copy files to the S3 storage.
For Rclone, I use the command “rclone copy --s3-v2-auth <filename> isilons3:<bucketname> --no-check-certificate” and can copy files to the S3 storage.

 

However, in Dataverse I still cannot connect and in the log I see the error: “java.io.IOException: ERROR: S3AccessIO - Failed to look up bucket <bucketname> (is AWS properly configured?): Unable to execute HTTP request: received handshake warning: unrecognized_name at edu.harvard.iq.dataverse.dataaccess.S3AccessIO.<init>(S3AccessIO.java:98)”

 

I have the following JVM options set (although I have tried enabling/disabling chunked-encoding, path_style, payload_signing in various configurations):

 

dataverse.files.iso.type=s3

dataverse.files.iso.label=isilons3

dataverse.files.iso.profile=isilons3

dataverse.files.iso.bucket-name=<bucketname>

dataverse.files.iso.custom-endpoint-url=<endpointURL>:<port>

dataverse.files.iso.custom-endpoint-region=

dataverse.files.iso.payload-signing=false

dataverse.files.iso.chunked-encoding=false

dataverse.files.iso.path-style-access=false

 

Default storage driver id is set to our AWS S3 bucket.

 

Does anyone have any suggestions considering I CAN actually successfully write to the bucket with command line tools, just using the given DNS and bucket name (ie: no path to the bucket is needed, although they did give me one). And, since I have to disable the SSL check, is there an option for Dataverse that does that?

 

I hope this makes sense. Would love to get this working and have another storage type that works!

 

Thanks!

Night Owl

James Myers

unread,
May 5, 2021, 12:12:29 PM5/5/21
to dataverse...@googlegroups.com

I would expect the AWSClient to try and validate the certificate from the server (what you’re bypassing with –no-verify-ssl in the command line) so my guess would be it is that rather than something related to your jvm options (and none of them disable cert validation).

 

In general, I think the best production answer would be to fix the certificate on the s3 store. If the issue is just that it is a self-signed certificate, one can update the list of trusted certificates java will accept.

 

Beyond doing that, to make it work with the current certificate, I think changes would be needed in the Java code to not verify the cert, which wouldn’t be good for production but would help test.

 

One more thought – the specific error “…unrecognized_name” suggests it may also be related to ‘Server Name Indication’ in the ‘TLS/SSL protocol’ – basically buzzwords, but that may be an issue even if the cert isn’t self-signed/is from a well-known cert vendor, and it is possible that there is some java level setting that would allow you to get around this without code changes in Dataverse – I’m not sure, but someone else may.

 

Hope that’s helpful,

 

-- Jim

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/BYAPR06MB4869342ABC86DA1B587EB41087599%40BYAPR06MB4869.namprd06.prod.outlook.com.

Deirdre Kirmis

unread,
May 5, 2021, 12:24:42 PM5/5/21
to dataverse...@googlegroups.com

Thanks, Jim!

So, on the server, we are not using a self-signed cert, but a wildcard cert that should cover our *.lib.asu.edu domain, which should actually include the endpoint URL used here. I do prefer validating the certificate so therefore eliminating the need for the –no-verify-ssl (wouldn’t want to do that in production anyway). Just not sure what I need to do to fix the certificate on the s3 store since we are using a valid cert (registered with InCommon). This is also a test server, and on the production server, it is a custom registered cert for the server domain (dataverse.asu.edu).

 

Night Owl

Don Sizemore

unread,
May 5, 2021, 12:32:25 PM5/5/21
to dataverse...@googlegroups.com
Deirdre,

UNC uses InCommon certs as well and, while most browsers recognize them, not all clients may. As Jim suggested, you might try adding it to the java store, or if you get the e-mailed links to download different formats, try a chained .pem or InCommon's cert-with-issuer-after?

Flinging spaghetti on the wall,
Don


James Myers

unread,
May 5, 2021, 12:54:13 PM5/5/21
to dataverse...@googlegroups.com

The SNI issue I mentioned would apply to *.lib.asu.edu certs, so asking/googling about that might help. I saw some info in a quick google search that suggested one could turn off using SNI but that was for older Java, so I don’t know if Java 11 also has a setting to disable using it. There may also be ways to configure the s3 side to send a valid name too – I just don’t know.

 

If that uncovers some setting we could/should change in Dataverse, it would be good to have an issue. (There was also an InCommon root cert issue a while back, but I think that was older Java only. Regardless – trying to add this cert/it’s root to your trust store as Don suggests would be a good thing to try).

Deirdre Kirmis

unread,
May 5, 2021, 12:56:49 PM5/5/21
to dataverse...@googlegroups.com

Thanks Don! Lately, I feel like like I’m slinging spaghetti on the wall a lot! =D

You both have helped so much! If I can figure out how to add the cert to the java store, I will try it!

 

Thanks again!

 

dk

Reply all
Reply to author
Forward
0 new messages