The security/compliance dep requires that all S3 buckets are encrypted and all CMK keys have a rotation enabled. By default, the datomic template does not do this. Can anyone confirm my expectation that making these changes to the CFTs ourselves will not break anything?

AFAIK the buckets are encrypted @dmarjenburgh with KMS, but not using server-side encryption

Why is there both :db/retractEntity and :db.fn/retractEntity?

@tslocke On-prem: :db.fn/retractEntity, Cloud :db/retractEntity

@joe.lane yeah I noticed that, but still wondering why.

Ahh, sorry, I can't answer that one 🙂

With the client API, it seems, :in $ [?a-collection ...] is not allowed. What is the right way to use a collection as a param to a query?

that is allowed

Ahh my bad it's :find [?coll ...] that's not allowed. Maybe I can rearrange...

Hey y'all! I'm walking a coworker through Datomic Cloud and he's getting an error on this dependency com.datomic/ion-dev {:mvn/version "0.9.234"} that says "Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact com.datomic:ion-dev:pom:0.9.234 from/to datomic-cloud (<s3://datomic-releases-1fc2183a/maven/releases>): Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: 1A3956EEC6ECF1D5; S3 Extended Request ID: 2BxntHvQDQbz3eWoJql9cAFjdsdX2/g0Xu6b5hO7PzOZCnWSkyBomo83Jdh6DGHFDQYDGWhV/js=)" Any ideas as to what his problem might be? This comes up when he runs clj -A:dev

https://forum.datomic.com/t/issue-retrieving-com-datomic-ion-dependency-from-datomic-cloud-maven-repo/508/3 @brian.rogers

We can't seem to get his ~/.m2/settings.xml solution to work

Anyone have any idea? It seems that we can't pull com.datomic/ion-dev {:mvn/version "0.9.234"} out of Datomic's S3 bucket on his side when he runs Clojure -A:dev while trying to work with the ion tutorial repository

He needs to have aws credentials

has he configured the aws-cli yet?

Yeah he has. He's been able to connect to our existing infrastructure and query our database that is running. That was when we'd removed the ion-dev from the deps.edn. But then of course he couldn't push any ions

in my deps edn I have this section

:mvn/repos {"datomic-cloud" {:url ""}
             "sonatype"      {:url ""}}

Do you?

The code we're working with (that works for me) looks like this https://github.com/Datomic/ion-starter/blob/master/deps.edn#L10

Oh wait

Yes we also have :mvn/repos {"datomic-cloud" {:url ""}}

do not have that sonatype part

shouldn't need that to use ions

the sonatype one that is

that's just access to maven central snapshots

I can't imagine it has to do with the deps as it's working fine for me on my side. And he has AWS permissions to access all the resources as he was able to query our database. It's just this connecting ion-dev dependency we can't seem to pull down

are there AWS env vars set?

and what is set in ~/.m2/settings.xml?

don't post anything secret, just trying to get what's configured

I thought so but how can we check for good measure? No such file existed in his /m2/ (I don't have one either) but he did try the structure here: https://clojure.org/reference/deps_and_cli#_procurers using the s3 and the maven-auth-repos using combinations of his creds found in /.aws/credentials and the creds he uses to sign into AWS but nothing came of it

oops hold on let me edit

echo $AWS_PROFILE
echo $AWS_ACCESS_KEY_ID
echo $AWS_SECRET_ACCESS_KEY

Ah darn he's just clocked out 15 minutes ago. If those do or don't work, how should we proceed?

the datomic-cloud s3 repo is not authenticated, so you should NOT have anything set in ~/.m2/settings.xml

None of those echo statements produce any output for me actually

Okay cool cool. I'll make sure he deletes that if he did end up keeping the file around.

Should those produce output for him?

one thing that is confusing is that you must have some aws env vars set, even though they will not be used to access the datomic-cloud repo

because reasons, the s3 provider will attempt to look up the region of the bucket holding the repo and while the bucket is public, the IAM check on the region lookup will fail if you don't have some (any!) credentials set

So then given that when we commented out the ion-dev, we were still able to use the bastion to connect to the database and run queries, and also able to pull in com.datomic/client-cloud {:mvn/version "0.8.78"} which I'm assuming is also hosted in S3, I couldn't quite see how the creds were not working

If we were to totally redo the creds, should we just delete his ec2 keypair, delete the ~/.aws, and try it all over?

I suspect things are working off the default creds

but the s3 repo provider is super old and may not even look at that stuff

I think it is worth setting those aws env vars to same as whatever you're using in credentials and see if it works

Where does $AWS_PROFILE come from? I see the other two in ~/.aws/credentials/

that specifies which profile in your credentials to use

you can export AWS_PROFILE=default to use the default

so that might be a good test

aws sts get-caller-identity may be useful

I've written down these suggestions and I'll report back the results tomorrow morning when my coworker is back online. Thanks for all the help! =]