This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-20
Channels
- # announcements (3)
- # beginners (63)
- # calva (1)
- # cider (24)
- # clj-kondo (98)
- # cljdoc (8)
- # cljsrn (19)
- # clojure (106)
- # clojure-conj (2)
- # clojure-europe (5)
- # clojure-italy (5)
- # clojure-nl (8)
- # clojure-spec (8)
- # clojure-uk (13)
- # clojuredesign-podcast (7)
- # clojurescript (54)
- # core-async (1)
- # cursive (3)
- # data-science (1)
- # datomic (19)
- # fulcro (7)
- # hoplon (1)
- # off-topic (3)
- # re-frame (13)
- # reitit (1)
- # shadow-cljs (234)
- # test-check (10)
- # tools-deps (59)
- # unrepl (1)
- # yada (20)
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?
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 ...
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.
the printConnectionInfo
configuration https://docs.datomic.com/on-prem/system-properties.html#transactor-properties
will prevent Datomic from logging storage password on startup
Thanks @U05120CBV My problem was that the peer logged the password, not the transactor. Or will putting this property also affect the peer?
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
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?Nope. REBL can be very useful, particularly it's ability to leverage the nav metadata that decorate Datomic results.
Have you used REBL before? If not, take a look here: http://rebl.cognitect.com
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.
@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?
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.