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