When trying to run new CL docker images based on Debian bookworm, I'm
getting errors like this:
```
Executing "step_script" stage of the job script 00:03
Using docker image
sha256:09d35b13e5a86639aa00b12c2f57561e55a6126c78f654df463f3c914e2eff31
for rpgoldman/ccl:latest with digest
rpgoldman/ccl@sha256:746098f1e5c7e82a4f1605817af3137a966b50b7d935caeb5b313f7d20841556
...
shell not found
```
Googling reveals [this gitlab
discussion](https://forum.gitlab.com/t/jobs-fails-shell-not-found-version-p…
following, which suggests a possible work-around, but that also contains
the following note:
> In my case gitlab-runner’s shell detection script was failing to
> stat the available shell executables due to an incompatibility between
> the container and the host, thus returning failure for every check and
> giving up with the “shell not found” error.
> This sometimes happens when running bleeding edge images on older
> hosts, but typically it’s more obvious and often presents itself as
> a filesystem permissions error or some other system call failure.
> Essentially, the binaries/libraries in the container are using
> new/modified system calls that the dockerd/containerd’s seccomp
> layer doesn’t understand yet. *Updating the host kernel and
> container runtime tends to fix this.* [italics added]
Is there any chance that the GitLab host needs a refresh?
Thanks,
R
Hi Philipp,
On Tue, Aug 27, 2024 at 8:16 AM Philipp Marek <philipp(a)marek.priv.at> wrote:
> > Does this affect anybody on this mailing list? Any comments with
> > respect to the stricter policy?
>
> - Thanks for the hard work
>
> - My biggest worry is about notifications and error messages to admin@
> not arriving
>
You mean because of the fact that more mails might classified as SPAM on
our host?
If that's your worry, I can say that that's not the impact of this setting:
the "quarantine" value is read from DNS by hosts processing mail claiming
to originate from the @common-lisp.net domain. These processors establish
the authenticity of the mail through SPF and DKIM. If the authenticity test
fails, the current setting ("none") has no effect on mail delivery. The
proposed value ("quarantine") does have effect on mail delivery: the value
requests to separate from the regular mail flow. Most mail providers do
this by sending those mails straight to SPAM.
Either way, we will receive reports from the big mail processing companies
(fastmail, zoho, microsoft, google, ...) describing what they did with mail
flow coming from @common-lisp.net. There are applications to process these
mails to have (visual) integrated reports; we don't have that software in
place at the moment. It would be nice to process the individual reports
into a visualization like that. Maybe that's something someone else can
work on.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Since a few weeks now, we're running DMARC for the mailing lists. So far,
we've run with the loosest policy possible ("none"). The other options are
"quarantine" and "reject".
I'm thinking we'll want mail sent using our domain (common-lisp.net),
failing the DMARC checks (failing SPF and/or DKIM), to be quarantined
(moved to SPAM) at the very least. I noticed that fastmail is using an even
stricter policy ("reject"), but moving straight from "none" to "reject"
seems too much (because "reject" prevents delivery; not just moving to
SPAM).
This will affect everybody using an @common-lisp.net mail address with
their own mail server.
Does this affect anybody on this mailing list? Any comments with respect to
the stricter policy?
Regards,
Erik.
Hi all,
Finally, I've been able to configure outgoing mail on common-lisp.net using
TLS on outbound connections. As it turns out, I had to resort to ACLs
(setfacl/getfacl) to assign Exim's primary group (Debian-exim) read access
to /etc/letsencrypt/{live,archive}. For some reason, being granted read
access through the secondary group, doesn't work for Exim and leads to
"Error reading file" messages in the logs.
On my test messages, GMail now reports that common-lisp.net used encryption
to send the mails.)
(Consider this mail to be a test-case for mails sent through the mailing
list software.)
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Since a few weeks now, we're running DMARC for the mailing lists. So
far, we've run with the loosest policy possible ("none"). The other
options are "quarantine" and "reject". This will affect everybody using
an @common-lisp.net domain for their mail while sending these mails from
their own service provider rather than injecting via common-lisp.net.
I'm thinking we'll want mail sent using our domain, failing the DMARC
checks, to be quarantined (moved to SPAM) at the very least. I noticed
that fastmail is using an even stricter policy ("reject").
Is it time to increase the barriers on (ab)using our domain? Will this
impact anybody on this list?
Regards,
Erik.
Hi,
In the mail server logs, I found:
2024-07-19 10:39:16 1sUl13-00EJCh-1P ** andy.arvid(a)gmail.com R=outbound
T=remote_smtp H=gmail-smtp-in.l.google.com [2a00:1450:400c:c04::1a]
X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes: SMTP
error from remote mail server after end of data: 550-5.7.1
[2a01:4f8:160:83c4::8 19] Gmail has detected that this message
is\n550-5.7.1 likely suspicious due to the very low reputation of the
sending\n550-5.7.1 domain. To best protect our users from spam, the message
has been\n550-5.7.1 blocked. For more information, go to\n550 5.7.1
https://support.google.com/mail/answer/188131
ffacd0b85a97d-368786b3865si463916f8f.529 - gsmtp
This is from sending my prior mail from a GMail account. The "
common-lisp.net" domain has a High (=highest) domain reputation and the IP
reputation is not published, but also not referred to. So I can nothing but
conclude this must be the @gmail.com address that I'm sending from that's
triggering this response?
How can I fight this?!
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Yesterday, I've changed the settings on the server to stop doing
sender/callout: verification of existence of the mail address of the
sender; although it's considered abuse (of the server of the owner of the
verified domain), it's been a very effective method of keeping spam in
check in the past. However, it seems to keep out some DMARC reports as well.
At the same time, I've changed the mail processing parameters: SPF is now
checked earlier in the mail transaction and instead of calling out to an
external application, it's processed by Exim's SPF capability internally.
This mail is both a heads-up as well as a test mail to see if mail still
comes through.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
Introduction of ARC signing and a DMARC DNS record seem to have satisfied
Google's bulk sender requirements again: the domain reputation has gone
back to High (from Medium since mid-June). Also, mails to GMail addresses
from our mailing lists are not being blocked by GMail anymore.
So far, so good. What's not working yet, is the mail forwarding service
where users have an @common-lisp.net address where the forward address is
hosted by Google. These mails are not being ARC signed; while Exim has an
(experimental) feature to apply ARC signing to mails, the maintainer(s) at
Debian will not consider enabling it (
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058808).
There are mail-filters (milters) in the Debian ecosystem which *will* allow
ARC signing for this mail flow, but Exim doesn't support milters under the
pretense that it is sufficiently extensible not to need that. Which is
probably true since they embed a Perl interpreter (why?!). On the other
hand, since milters are a generally accepted extension mechanism for mail
servers, the combination of positions taken by the Exim developers and the
Debian Exim packagers, is rather unfortunately resulting in the fact that
we can't forward mail to Google...
I'm open to ideas or options that I may have missed while doing my research
for solutions.
Regards,
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.