This reverts commit 8231c3e833.
Truned out this workaround was not sufficient, see the follow-up in
commit 191cc1b952 for details.
But possibly the second one does it on its own? Reverting this for
a test run.
Turns out the workaround in $WaitForFile (commit
8231c3e833) is not sufficient. It helps
sometimes, but not always. Possibly depends on CPU speed and bandwidth
of internet connection... Who knows!? 🤪
But! Reading the file goes beyond the known file size. That's suspicious
and indicates this exact issue. So add a delay, and keep reading until
sizes are equal.
This used to require a key=value store, separated with commas. An
example for `netwatch-notify` is:
/tool/netwatch/add comment="notify, name=example.com" host=93.184.215.14;
Now JSON is supported as well, so you could use:
/tool/netwatch/add comment="{\"notify\":true,\"name\":\"example.com\"}" host=93.184.215.14;
Looks more clumsy here, but may be of help in more complex setups...
Well, turns out that waiting for existence of a file is not sufficient.
Chances are that a file is available just partly, so wait until the size
no longer changes... Let's hope that works as expected. 🤞
... to have a clean way to generate bitmasks.
[admin@mikrotik] > :put [ $VersionToNum 0.255zero0 ]
16711680
[admin@mikrotik] > :put 0x00ff0000
16711680
Once implemented everywhere the internal calculation could be
changed easily.
Note that literal "true" or "false" (even without quotes) is converted
to string. So you may have to enclose it in parentheses for a boolean
value:
> :put [ :typeof [ $EitherOr true false ] ];
str
> :put [ :typeof [ $EitherOr (true) (false) ] ];
bool
Adding this in `global-config-overlay` make the scripts being stored
with CRLF line breaks:
:global ScriptUpdatesCRLF true;
Handle with care, I do not recommend it. Thus it's just a hidden
setting.
In the beginning of Let's Encrypt their root certificate ISRG Root X1
was not widely trusted, at least some older and/or mobile platforms were
missing that certificate in their root certificate store.
At that time Let's Encrypt was using an alternative chain of trust,
where a certificate was cross-signed with DST Root CA X3.
To make sure a valid chain of trust is available under all circumstances
a set of all certificates had to be supplied: both root vertificates
ISRG Root X1 & DST Root CA X3, and an intermediate certificate.
This was still true after DST Root CA X3 expired, as it could still be
used as a root anchor and was shipped by Let's Encrypt when requested. 🤪
This time is finally over, and we have a clean chain for trust ending in
ISRG Root X1 (or ISRG Root X2).
Well, actually it is the other way round... Let's Encrypt signs with
different tantamount intermediate certificates. There is not only E5, but
also E6 - and we can not know beforehand which one is used on renew.
So let's jetzt drop the intermediate certificates now, and rely on root
certificates only. We are perfectly fine with this these days.
Follow-up commits will do the same for *all* certificates.
The certificate is downloaded with:
curl -d '["ISRG Root X2"]' https://mkcert.org/generate/ | grep -v '^$' > certs/ISRG-Root-X2.pem
... as we still want to deduplicate it when it is inside the input
string. This also unbreak certificate import for "Go Daddy Secure
Certificate Authority - G2" (and more)...
