Good catch. The remotes need to be git@git.common-lisp.net or git@gitlab.common-lisp.net. There may never again be a guarantee that these will resolve to the same host as toplevel common-lisp.net

Any remotes which reference @common-lisp.net are wrong and need to be updated, even though they may have worked accidentally with the old setup ( they will not work for pushing now, because the old setup is permanently in read only mode until someday it will disappear completely..)

Apparently, the read-only setting is  a good thing too, or we would already be looking at synchronization hell.

Dave Cooper

---- On Fri, 27 Dec 2024 20:24:11 -0500 ipmonger@delamancha.org wrote ----

Here's the problem for people who have already created clones - their remote url is leveraging git@common-lisp.net instead of git@gitlab.common-lisp.net.  I used this in my cmucl/cmucl repo and problem is resolved for that repo.  How to fix it more generally, though?

git remote set-url origin git@gitlab.common-lisp.net:cmucl/cmucl.git

Also, for cmucl/cmucl, the runners that existed before no longer seem to be defined, so my recent push to a branch has the check jobs stalled due to no eligible runners.

—jon

On Fri, Dec 27, 2024 at 7:58 PM Raymond Toy toy.raymond@gmail.com wrote:

On Fri, Dec 27, 2024 at 4:49 PM Dave Cooper dcooper8@gmail.com wrote:

I can pull, but can't push.  And now I can't reach gitlab.c-l.net anymore; I'm unable to connect again.

Well, the website is definitely up. Not for me.  And adding an entry in my /etc/hosts file doesn't work; it did before.

What happens when you try to push?  It says it's read-only.  And check my access rights.

Superstition, but try logging out and back in.  No joy. :-(

Am I the only one having trouble?  Lucky me!

--

Ray

Hi Jon and Ray,

---- On Fri, 27 Dec 2024 22:10:57 -0500 Raymond Toy toy.raymond@gmail.com wrote ---

On Fri, Dec 27, 2024 at 5:24 PM Jon Boone mailto:ipmonger@delamancha.org wrote:

Here's the problem for people who have already created clones - their remote url is leveraging mailto:git@common-lisp.net instead of mailto:git@gitlab.common-lisp.net.  I used this in my cmucl/cmucl repo and problem is resolved for that repo.  How to fix it more generally, though?

git remote set-url origin mailto:git@gitlab.common-lisp.net:cmucl/cmucl.git

Aargh.  I did this.  git pull complains that the connection to ssh on port 22 failed.  git push just hangs for at least 30 sec.  No message before I killed it.

Let's get your basic connectivity stabilized before troubleshooting that part further.

Also, for cmucl/cmucl, the runners that existed before no longer seem to be defined, so my recent push to a branch has the check jobs stalled due to no eligible runners.

I'll look into the runners issue.

Hmm.  I'd look into this, but I still can't access gitlab from my browser.  I even tried https://65.108.13.229.%C2%A0 Still unreachable.

The raw IP address wouldn't be expected to bring you to the gitlab instance, as this host is set up with several virtual hosts, including the gitlab., specified by name only.

But, it still should be reachable and give some kind of response. So this again points to a recurring basic connectivity issue.

And curiously, I can't ssh to http://gitlab.common-lisp.net anymore.

I'm going to be away for a few days so I won't be able to do any more testing.  But from what I can tell, this is mostly an issue on my end.  Lucky me!

Ray, I do hope (for our sake) that your basic connectivity issues are indeed on your end. For your sake, assuming it is on your end, I hope it ends up being something simple/obvious once you find it.  In any case, your attempts and reports have already helped us uncover several show-stopper issues on our end.

Jon, here's a possible plan to narrow down any remaining on-our-end issues for Ray while he's away:

1.  Generate a fresh ed25519 keypair (for temporary/testing use)

2.  Impersonate rtoy in the gitlab instance (as an Admin, you'll see an "Impersonate" button at the upper-right in the rtoy User page)

3.  Go into rtoy's "SSH Keys" in the sidebar under User Preferences (user icon under upper-left Gitlab icon) and paste the public key of the keypair from step 1).

4.  Temporarily edit your home .ssh/config to specify the user rtoy and the private key from step 1) for connecting to the host gitlab.common-lisp.net.   5.  Pull one of rtoy's repositories, make a new branch and make an innocuous change on that branch, try to push.

if the above works, then we can assume that any remaining problems are indeed with Ray's local config. First step there is to figure out his basic connectivity issue manifested by not even being able to visit gitlab.clnet. Make sure he can reliably visit gitlab.clnet in the browser before proceeding with the next step. Next step: share the above private/public keys with Ray along with your .ssh/config entry and have him try with that setup.

Note that following the above steps will not enable actually ssh'ing into the host -- that would require also adding the public key to rtoy's .ssh/authorized_keys (you can test that too if you'd like).

If you have other ideas, please follow your instinct. I will look into the runners now.

Dave

FYI

I just did a push to gitlab (repo:XHTMLambda) and it worked. Bu I do not remember when exactly I updated my setup.

All the best

Marco

On Sat, Dec 28, 2024 at 6:28 AM Jon Boone ipmonger@delamancha.org wrote:

Ray, use port 4022 instead of 22 on the remote set-url command - git@gitlab.common-lisp.net:4022/cmucl/cmucl.git - and see if that helps for that one repo. I can help you with your local issues (DNS, etc) when you get back…

—jon On Dec 27, 2024 at 23:07 -0500, David Cooper david.cooper@genworks.com, wrote:

Hi Jon and Ray,

---- On Fri, 27 Dec 2024 22:10:57 -0500 *Raymond Toy <toy.raymond@gmail.com toy.raymond@gmail.com>* wrote ---

On Fri, Dec 27, 2024 at 5:24 PM Jon Boone ipmonger@delamancha.org wrote:

Here's the problem for people who have already created clones - their remote url is leveraging git@common-lisp.net instead of git@gitlab.common-lisp.net. I used this in my cmucl/cmucl repo and problem is resolved for that repo. How to fix it more generally, though?

git remote set-url origin git@gitlab.common-lisp.net:cmucl/cmucl.git

Aargh. I did this. git pull complains that the connection to ssh on port 22 failed. git push just hangs for at least 30 sec. No message before I killed it.

Let's get your basic connectivity stabilized before troubleshooting that part further.

Also, for cmucl/cmucl, the runners that existed before no longer seem to be defined, so my recent push to a branch has the check jobs stalled due to no eligible runners.

I'll look into the runners issue.

Hmm. I'd look into this, but I still can't access gitlab from my browser. I even tried https://65.108.13.229. Still unreachable.

The raw IP address wouldn't be expected to bring you to the gitlab instance, as this host is set up with several virtual hosts, including the gitlab., specified by name only.

But, it still should be reachable and give some kind of response. So this again points to a recurring basic connectivity issue.

And curiously, I can't ssh to gitlab.common-lisp.net anymore.

I'm going to be away for a few days so I won't be able to do any more testing. But from what I can tell, this is mostly an issue on my end. Lucky me!

Ray, I do hope (for our sake) that your basic connectivity issues are indeed on your end. For your sake, assuming it is on your end, I hope it ends up being something simple/obvious once you find it. In any case, your attempts and reports have already helped us uncover several show-stopper issues on our end.

Jon, here's a possible plan to narrow down any remaining on-our-end issues for Ray while he's away:

1. Generate a fresh ed25519 keypair (for temporary/testing use)
2. Impersonate rtoy in the gitlab instance (as an Admin, you'll see an

"Impersonate" button at the upper-right in the rtoy User page) 3. Go into rtoy's "SSH Keys" in the sidebar under User Preferences (user icon under upper-left Gitlab icon) and paste the public key of the keypair from step 1). 4. Temporarily edit your home .ssh/config to specify the user rtoy and the private key from step 1) for connecting to the host gitlab.common-lisp.net. 5. Pull one of rtoy's repositories, make a new branch and make an innocuous change on that branch, try to push.

if the above works, then we can assume that any remaining problems are indeed with Ray's local config. First step there is to figure out his basic connectivity issue manifested by not even being able to visit gitlab.clnet. Make sure he can reliably visit gitlab.clnet in the browser before proceeding with the next step. Next step: share the above private/public keys with Ray along with your .ssh/config entry and have him try with that setup.

Note that following the above steps will not enable actually ssh'ing into the host -- that would require also adding the public key to rtoy's .ssh/authorized_keys (you can test that too if you'd like).

If you have other ideas, please follow your instinct. I will look into the runners now.

Dave

On 12/28/24 5:46 AM, David Cooper wrote:

To clarify: we can forget port 4022 for now in any remote urls or client configs. There had been a dangling 4022 in the new gitlab config for ssh urls, but that is fixed now. So now, we are on the standard port 22, which does not need to be specified.

I’m back, and everything seems to be working fine again. I didn’t change anything after coming back, but the merge button works, I can push changes and ssh to gitlab.common-lisp.net on port 22.

And my VirtualBox runners are running.

Thanks to everyone for their hardwork in resolving this issue. And may the New Year be an uneventful year for all of the hard working people at c-l.net!

&#8203;