curl -l -g --data '{"args" : { "pem" : "$(cat fullchain.pem)", "key" : "$(cat privkey.pem)" } }' -u "username:password" -X GET http://[IP_ADDRESS]/api/ssl/cert_import
, and that being the renew hook for that cert). It's been working well from June of 2020 until ~16 Nov 21. But at that time, a renewed cert was issued, but installing the cert failed.{"error":"invalid character '\\n' in string literal"}#
. I assume it's griping about the fact that the cert/key files contain newline characters--as will always be the case.The team is working on TC2.2 and very busy... it should get reviewed prior to that. Is anyone else having the issue?Any reason why TC-2027 as still not been reviewed weeks after its creation ? Because it is a known issue that is back, it should be easy to fix. Original was rated High, acknowledging it is a significant one...
@morganL, @aervin, any clue why is that ? Any intention to get that one fixed once and for all ?
Technically everyone has the issue.... As of now, no one has DNS redundancy. How many end up blocked on their primary DNS like me is probably a very low percentage but how many think they have DNS redundancy when in fact they do not, probably most if not everyone...Is anyone else having the issue?
Technically everyone has the issue.... As of now, no one has DNS redundancy. How many end up blocked on their primary DNS like me is probably a very low percentage but how many think they have DNS redundancy when in fact they do not, probably most if not everyone...
Doesn't it depend on how you deploy the TC container...
what approach are you using?
Can you use the host DNS?
Is there a workaround with docker compose or Kubernetes?
TrueCommand itself is not a high availability application.... the infrastructure needs to protect it.
Reported as https://jira.ixsystems.com/browse/TC-2063error message back from TrueCommand:{"error":"invalid character '\\n' in string literal"}#
.
Reported as https://jira.ixsystems.com/browse/TC-2064But worse is that when I paste in the cert and key files through the TrueCommand GUI, it appears to take them, and it saves them to disk (/data/truecommand/server.crt.custom and server.key.custom), but it doesn't actually serve them; it continues serving the old, expired cert.
So, the bug is only when the secondary DNS address is within the same docker complex?The details are in TC-1812. The bug is created because the docker host is using its own external IP address as a DNS but docker's routing makes the DNS reply comes from the internal docker IP. The result is the DNS reply is not from the expected IP and is discarded for security reason.
I never saw a single software / operating system / appliance that was not designed to handle at least 2 DNS servers. DNS is so critical for everything, the capability to probe more than one is not considered as high availability. It is standard operation.
No, the bug is that TrueCommand tries only its first DNS and never probes its secondary DNS.So, the bug is only when the secondary DNS address is within the same docker complex?
Its really a limitation of docker networking and the lack of IP address transparency.
Do other Apps accepts DNS responses from another IP address?
Thanks.. my misunderstanding. The first DNS was failing due to docker networking, but the second DNS failing is due to TrueCommand,No, the bug is that TrueCommand tries only its first DNS and never probes its secondary DNS.
No. What makes MY primary DNS fails is a docker networking problem. A primary DNS may fail for many reasons.... For TrueCommand, it does not matter WHY its primary DNS failed. Whenever the primary fails, it MUST probes its secondary DNS.
Yes. From inside TrueCommand's container when TrueCommand fails to prove its secondary DNS, OpenSSL succeeds to contact my TrueNAS server calling it by its name. It takes a few seconds for the primary DNS request to fail and the second to succeed but after these few seconds, OpenSSL does connect my server by its name when TrueCommand can not.
Thanks.. my misunderstanding.
but the second DNS failing is due to TrueCommand,
I assume that is the case for either host-based DNs information or container-based?