Re: Can pull but cannot push

Marco Antoniotti <[email protected]> Sat, 28 Dec 2024 10:36:48 +0200
Newsgroups gmane.lisp.common-lisp-net.devel
Message-ID <CAG0Nw2mP1dn5Y-++SyT=X3VFKKbNMb05YJJvN5nedAKPWKUgAQ@mail.gmail.com>
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 <[email protected]> wrote:

> Ray, use port 4022 instead of 22 on the remote set-url command -
> [email protected]: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 <[email protected]>,
> wrote:
>
> Hi Jon and Ray,
>
> ---- On Fri, 27 Dec 2024 22:10:57 -0500 *Raymond Toy
> <[email protected] <[email protected]>>* wrote ---
>
>
> On Fri, Dec 27, 2024 at 5:24 PM Jon Boone <[email protected]> wrote:
>
> Here's the problem for people who have already created clones - their
> remote url is leveraging [email protected] instead of
> [email protected].  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 [email protected]: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
>
>
>
>
>
>
>
>
>

-- 
Marco Antoniotti, Professor, Director         tel. +39 - 02 64 48 79 01
DISCo, University of Milan-Bicocca U14 2043   http://dcb.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY