One of the members of the ASDF-devel list forwarded this to me because of the cryptic bounce message.
Forwarded message:
> From: phoebe Goldman <phoebe(a)goldman-tribe.org>
> To: Robert Goldman <rpgoldman(a)goldman-tribe.org>
> Subject: can't reply to asdf list Fwd: Undelivered Mail Returned to Sender
> Date: Tue, 26 Apr 2022 09:29:53 -0400
>
> with or without gpg signature, my emails get bounced.
>
>> Begin forwarded message:
>>
>> From: MAILER-DAEMON(a)smtp2.us.opalstack.com (Mail Delivery System)
>> Subject: Undelivered Mail Returned to Sender
>> Date: April 26, 2022 at 9:28:40 AM EDT
>> To: phoebe(a)goldman-tribe.org
>>
>> This is the mail system at host smtp2.us.opalstack.com.
>>
>> I'm sorry to have to inform you that your message could not
>> be delivered to one or more recipients. It's attached below.
>>
>> For further assistance, please send mail to postmaster.
>>
>> If you do so, please include this problem report. You can
>> delete your own text from the attached returned message.
>>
>> The mail system
>>
>> <asdf-devel(a)common-lisp.net>: host mail.common-lisp.net[148.251.208.23] said:
>> 550 Administrative prohibition (in reply to end of DATA command)
>> Reporting-MTA: dns; smtp2.us.opalstack.com
>> X-Postfix-Queue-ID: 1334DC3761
>> X-Postfix-Sender: rfc822; phoebe(a)goldman-tribe.org
>> Arrival-Date: Tue, 26 Apr 2022 13:28:31 +0000 (UTC)
>>
>> Final-Recipient: rfc822; asdf-devel(a)common-lisp.net
>> Original-Recipient: rfc822;asdf-devel(a)common-lisp.net
>> Action: failed
>> Status: 5.0.0
>> Remote-MTA: dns; mail.common-lisp.net
>> Diagnostic-Code: smtp; 550 Administrative prohibition
>>
>> From: phoebe Goldman <phoebe(a)goldman-tribe.org>
>> Subject: Fwd: Define a Simple Echo-Op
>> Date: April 26, 2022 at 9:28:31 AM EDT
>> To: asdf-devel(a)common-lisp.net
>>
>>
>> Forwarding without GPG signature, because my signed email got bounced by the mailing list. :/
>>
>>> Begin forwarded message:
>>>
>>> From: phoebe Goldman <phoebe(a)goldman-tribe.org <mailto:phoebe@goldman-tribe.org>>
>>> Subject: Re: Define a Simple Echo-Op
>>> Date: April 26, 2022 at 9:26:39 AM EDT
>>> To: zacque <technical+asdf-devel(a)zacque.tk <mailto:technical+asdf-devel@zacque.tk>>
>>> Cc: asdf-devel(a)common-lisp.net <mailto:asdf-devel@common-lisp.net>
>>>
[...snip...]
Hi,
common-lisp.net GitLab instance is set to maintenance mode since last night
due to unexpected outage: around 19.20 CEST, phoe approached me on the
common-lisp.net:matrix.org chat channel (a.k.a. #common-lisp.net:libera.chat)
about the unavailability of the with-contexts project. Logging into the
system, it quickly became apparent that one of the discs had filled up,
causing this failure. After a bit of research, it became apparent that some
23GB (less than 10% of space on the volume) of disc space was taken by
Prometheus. A tool we're not using, but which comes out of the box with
GitLab. Disabling Prometheus and removing its files quickly freed up enough
space for basic web requests to work again.
To have some more room for various processes to operate with, I'm using a
maximum of 80% fill-rate for the volumes in the VM. So, I went looking for
more possibilities to clean out storage. At one point, I ended up GitLab's
PostgreSQL directory, where there was a little more than a GB of storage to
be won. Not a lot, but since I was cleaning anyway, it seemed like a good
thing to look at. There were clearly old Pg clusters (various Pg10 and Pg11
clusters while we were running on 12). There also was a script called
"delete_old_clusters.sh". It seemed better to use a script from the vendor
than meddling with the database data myself, so I used it. HOWEVER: it
immediately and without warning *removed the production database* (contrary
to the expectation that it would remove the *old* clusters laying around)!
Although this is rather unfortunate, series of events, I quickly recovered
from the heart attack that followed; turned off as many services on the
machine as possible and searched (a) for older database copies and (b) for
dumped backups. Unfortunately, misforture never comes alone: as soon as I
found the backup, I realized it's from Feburary 27th. The backup system
that had been running without problems for *years* had stopped running
after March 1st and none of the current maintainers noticed: since the
backup procedure didn't generate an error, but was plainly not executed,
there were no mails about backups failing. On top of that, it turns out
that the system I have in place to report disk usage problems, wasn't
delivering messages of the common-lisp.net disk overage either!
I've restored the database backup from the 27th and we have the backup
procedure running again. This means that anything stored in the database is
back to the 27th. MRs, issues, etc. The *repositories* are fine and never
were in danger!
So far, I've waited to enable the service, because I've contacted the
#gitlab:libera.chat channel to ask if anything can be done to assure
consistency between the repositories and the database. So far, the channel
has remained silent (not just to my question, but to any questions posed).
I am thinking to restore access on monday night CEST, if no answer appears
on the gitlab channel, or as much earlier as a usable answer will be
provided.
Let me close off this mail by offering my sincere apologies for failing the
trust you have put in me and for any inconvenience this may have caused.
Please report any inconsistencies you run into to admin at common-lisp.net
so we can work on fixes. Additional controls are being worked on to prevent
a similar situation in future: "ping" messages from the monitoring
infrastructure and checks on the off-site backup system to check that the
weekly full backup (and the daily incrementals) have been delivered.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi
I cannot access anymore my repository CL-PLOT. It seems like it
disappeared....
Can you check what happened?
All the best
Marco
--
Marco Antoniotti, Professor tel. +39 - 02 64 48
79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
For a long time, we had release and snapshot tarballs at
https://common-lisp.net/project/cmucl/downloads/. But this now no longer
works and a 403 Forbidden error is returned.
This also breaks cmucl's CI that pulls snapshot tarballs for running CI.
According to https://gitlab.common-lisp.net/cmucl/cmucl/-/pipelines, it was
working a week ago, but has now stopped working.
I have no problem updating docs and CI to use a new path, but I don't know
what it would be.
(It still seems reachable via rsync, though.)
--
Ray
Hi
I am trying to import a repo in Gitlab. I just created the repo using the
web interface (CL-PLOT).
This is what the instructions on the site say.
cd existing_repo
git remote rename origin old-origin
git remote add origin git@common-lisp.net:mantoniotti/cl-plot.gitgit
push -u origin --all
git push -u origin --tags
Once I try git push I get the dreaded message.
$ git push -u origin --all
git(a)common-lisp.net: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Why? I.e., why doesn't git understand the 2FA I set up a long time ago?
Why I cannot get my SSH keys to work? How can I change the remote spec in
order not to have to go through this every other month?
Thank you
All the best
Marco
--
Marco Antoniotti, Professor tel. +39 - 02 64 48
79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Sadly, Elias (`epipping`) passed away about 5 years ago. He still gets
emails that go to his mother, who finds them a little distressing.
I cannot remove him from ASDF because he is listed as an Owner on the
project.
Probably it would be best to shut down his common-lisp.net account.
Best,
Robert
Hi
I have a repository I have not touched in a while and now I cannot push to
gitlab. I use Sourcetree.
I have TFA on and a personal token. I also have ssh public keys uploaded,
but I cannot find the right incantation to set things up. I understand
there is something I must do with the personal token, but what exactly?
The Gitlab instructions are a bit cryptic for me.
Please advise.
Thanks.
--
Marco Antoniotti, Professor tel. +39 - 02 64 48
79 01
DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY