clo-devel

clo-devel@common-lisp.net

1 participants
612 discussions

Re: Quick question about cl.net github actions
by Robert Goldman 17 Dec '24

17 Dec '24

Thanks, Dave -- I'm trying to get into gitlab-future.common-lisp.net, and having a problem. I don't have the 2FA device I had configured on gitlab.common-lisp.net, which isn't a problem there, because I have a passkey set up. But the passkey does not seem to have migrated to gitlab-future.common-lisp.net, so I am unable to log in. Could you perhaps disable the 2FA on g-f.cl.net so that I can reset it? Sorry about the nuisance, Thanks, R On 17 Dec 2024, at 11:12, David Cooper wrote: > Hi Robert, > > > > We are in the process of migrating gitlab.common-lisp.net to the new > host, currently gitlab-future.common-lisp.net. > > > > https://gitlab-future.common-lisp.net is up and running and it's > been restored from a recent backup of the production host - so if > you'd like, you can test the pipeline in question on > gitlab-future.common-lisp.net -- it may or may not work completely but > at least you can see if it hits a different issue from what you are > seeing on the legacy host. > > > > We're hoping to do the cutover to the new gitlab host possibly by the > end of the year, and it will be great if we can confirm that the > docker pipeline issue you were hitting is indeed not an issue on the > upgraded host. > > > > > > > > Dave Cooper > > > > > > > > > ---- On Tue, 17 Dec 2024 11:39:33 -0500 Robert Goldman > <rpgoldman(a)sift.info> wrote --- > > > > Sorry to bother you, but wondering -- did the CI issue with the Gitlab > runner not being able to run newer docker images get fixed? That's > the one where the Gitlab runner claims it can't find the shell when > running some newer docker images. > > I was going to fix up some issues in the ASDF pipelines, but I think > that's a blocker.

1 0

Quick question about cl.net github actions
by Robert Goldman 17 Dec '24

17 Dec '24

Sorry to bother you, but wondering -- did the CI issue with the Gitlab runner not being able to run newer docker images get fixed? That's the one where the Gitlab runner claims it can't find the shell when running some newer docker images. I was going to fix up some issues in the ASDF pipelines, but I think that's a blocker.

1 0

Re: Discourse Requirements
by Mark Evenson 19 Nov '24

19 Nov '24

> On Jun 18, 2022, at 18:11, Chris Moore <moore.christopher515(a)gmail.com> wrote: > > Hey Mark! > > If it makes it easier for the foundation, I can get the host together myself (paying for w/e architecture) and get a proof of concept out for the board to review prior to attaching any kind of DNS record. Not necessary for you to get the host yourself. Sorry to have been a little recalcitrant over the last week, but I have just started a new job with <https://status.im> which has been occupying my time. Erik Hülsmann, a CLF board member, rents <https://hetzner.de/> instances for his CRM company which he essentially donates to the CLF at less than costs, so spinning up a host is no problem. We have standardized on Debian over Ubuntu as it makes the licensing situation clearer when we need a “special case”. Is there any reason you couldn’t install Discourse in the manner you wish under Debian? > > This includes me setting up whatever mail server, getting our daily backups together, and adding necessary plugins (GitHub/Gmail OAuth). If necessary, we would federate the `USER(a)common-lisp.net` domain. Currently we are running exim as the main MTA due to legacy concerns with mailman2 databases, but we wish to transition to a toplevel `postfix` that will work with the legacy `exim` for the `mailman2` app. > > I apologize for trying to rush this - I've got a lot of free time currently due to a lull in work going on at my current company. So I and the dev team are currently not doing much. I want to take advantage of the time while I can. Cool. Let’s take advantage of it. > > Let me know and I'll get this out the door ASAP. Can you please provide me with the public half of a contemporary-strength SSH keypair. We’ll set up a host, and communicate root@HOST via ip4/6 under separate cover. yours, Mark P.S. if you wanna find me online, let’s figure out a Discord rendezvous. I’m <discord:347061732705042435> aka <discord:easye#8466>. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

btrfs on future host (UFW is gone), gitlab switchover imminent
by David Cooper 14 Nov '24

14 Nov '24

Hi Philipp, Do I recall correctly that UFW was getting in your way of installing btrfs? Well, we've uninstalled ufw and installed nftables now (with iptables compatibility layer). Assuming ufw was the main problem, would you be able to look at the btrfs conversion process again? By the way, SAL9000 and I are in a new room on libera.chat - ##clnet-futurehost and aiming to switch over the gitlab during an upcoming weekend. Dave Cooper

2 1

Problem with new Docker images and GitLab actions at cl.net
by Robert Goldman 19 Sep '24

19 Sep '24

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

2 1

Re: Now that mail transfer is encrypted: stricter DMARC?
by Erik Huelsmann 27 Aug '24

27 Aug '24

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.

1 0

Now that mail transfer is encrypted: stricter DMARC?
by Erik Huelsmann 26 Aug '24

26 Aug '24

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.

2 1

Exim changes: encrypted mail outflow
by Erik Huelsmann 26 Aug '24

26 Aug '24

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.

1 0

Testing email
by Raymond Toy 22 Aug '24

22 Aug '24

Just testing if I can send email here, after the latest DMARC changes. -- Ray

2 1

Stricter DMARC?
by Erik Hulsmann 04 Aug '24

04 Aug '24

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.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

clo-devel