Fork me on GitHub
#datomic
<
2019-08-20
>
Ivar Refsdal07:08:53

When I connect to a database with an url like "datomic:", Datomic will by default log this password in plaintext. Is it possible to avoid this? Would it help using a map syntax for the connect call?

Lone Ranger09:08:40

Is this for corporate security policy? Are you running on a linux server? Does the message appear at initialization? Not a perfect answer but if the answer to the above questions are "yes" you could always use awk to filter out the password logging line ...

Ivar Refsdal12:08:35

The message appears when doing (d/connect) (default log-level is info), so yes that is during initialization. I've "solved" it using a timbre log middleware. Nevertheless I think it's bad practice by Datomic to log passwords in plaintext by default.

marshall13:08:13

the printConnectionInfo configuration https://docs.datomic.com/on-prem/system-properties.html#transactor-properties will prevent Datomic from logging storage password on startup

Ivar Refsdal08:08:05

Thanks @U05120CBV My problem was that the peer logged the password, not the transactor. Or will putting this property also affect the peer?

marshall13:08:03

Ah, i misunderstood. I don’t believe that will affect the peer

marshall13:08:46

That seems like something that should be registered as an improvement request Can you access the feature request portal (link in top menu bar of http://my.datomic.com dashboard)? If so, that would be a great one to add

grzm15:08:10

I have a Datomic Ion which is called by a scheduled Cloudwatch event every 10 minutes. 8-9 times out of 10 I get the following error in the logs for the lambda:

{:cognitect.anomalies/category :cognitect.anomalies/unavailable, :cognitect.anomalies/message "Connection reset by peer", :clojio/throwable :java.io.IOException, :clojio/socket-error :receive-header, :clojio/at 1566310809474, :clojio/remote "[ip redacted]", :clojio/queue :queued-handler, :datomic.ion.lambda.handler/retries 0}
The function called by the lambda seems to be executing fine: I cast an ion event during execution and can see that in the corresponding Datomic compute logs. Viewing the CloudWatch metrics for the lambda via the console also don't show these errors, so I think the ion is actually working fine. What do these anomalies indicate?

m0smith15:08:14

Is there a Datomic Console deployed with Datomic Ions/Cloud?

grzm15:08:56

Nope. REBL can be very useful, particularly it's ability to leverage the nav metadata that decorate Datomic results.

m0smith18:08:30

How do I get REBL running with ions?

grzm18:08:06

Have you used REBL before? If not, take a look here: http://rebl.cognitect.com

grzm18:08:08

If you've got REBL up and running, have your datomic-socks-proxy running, and Datomic query results are navigable using REBL. It's been years since I used the Datomic console, so I can't provide a great comparison, but I've found REBL to be really useful, in general, and when coupled with Datomic.

grzm18:08:39

There's really nothing special about ions in particular wrt REBL.

Joe Lane15:08:00

@grzm I think the aws lambda may have timed out (jvm startup) but the execution was still performed. What happens if you decrease the CW event to every 2 minutes?

grzm16:08:20

Cheers! That seems to be it. Would be helpful if the error were more explicit. The total time reported in the lambda logs is well under the lambda timeout, so the issue wasn't immediately apparent to me.

grzm16:08:47

Given that I don't want to actually run the code at such a low frequency, I'm thinking of setting up a second CloudWatch rule to call the same ion, but switch on the input, no-oping the rule that's keeping it warm. Does this seem sane?

Joe Lane16:08:08

Can you expose it through http direct? CW events can issue http calls

grzm16:08:16

Oh, that's an idea.