Was sent here by CCL/Mike (UTC +1) as per their instructions.
OS Name/Version: Ubuntu server. 24.04 live server amd64
Product Name/Version: AMP instance manager version 2.6.0
Problem Description: when installing AMP on a fresh install of Ubuntu server 24.04.1, the following error message pops up ’ Err:4 ahttps://cdn-repo.c7rs.com debian/ InRelease Could not handshake: Error in the pull function. ’
note that i have added an ‘a’ in some URLs to bypass the 2 link limit for new users. i have made them bold as well
LOGS/CONSOLE MESSAGES
--2025-02-03 04:51:16-- **ahttps://repo.cubecoders.com/archive.key**
Resolving repo.cubecoders.com (repo.cubecoders.com)... 198.244.186.210, 2001:41d0:800:1e2b::c00b:c0de
Connecting to repo.cubecoders.com (repo.cubecoders.com)|198.244.186.210|:443... connected.
HTTP request sent, awaiting response... 302 Redirect
Location: **ahttps://cdn-repo.c7rs.com/archive.key** [following]
--2025-02-03 04:51:17-- **ahttps://cdn-repo.c7rs.com/archive.key**
Resolving cdn-repo.c7rs.com (cdn-repo.c7rs.com)... 104.26.1.207, 172.67.74.30, 104.26.0.207, ...
Connecting to cdn-repo.c7rs.com (cdn-repo.c7rs.com)|104.26.1.207|:443... connected.
Unable to establish SSL connection.
Get:1 **ahttps://packages.adoptium.net/artifactory/deb** noble InRelease [7,511 B]
Hit:2 **ahttp://sg.archive.ubuntu.com/ubuntu noble** InRelease
Hit:3 **ahttp://security.ubuntu.com/ubuntu noble-security** InRelease
Hit:4 **ahttp://sg.archive.ubuntu.com/ubuntu noble-updates** InRelease
Hit:5 **ahttp://sg.archive.ubuntu.com/ubuntu noble-backports** InRelease
Ign:6 **ahttps://cdn-repo.c7rs.com** debian/ InRelease
Ign:6 **ahttps://cdn-repo.c7rs.com** debian/ InRelease
Ign:6 https://cdn-repo.c7rs.com debian/ InRelease
Err:6 https://cdn-repo.c7rs.com debian/ InRelease
Could not handshake: Error in the pull function. [IP: 104.26.0.207 443]
Fetched 7,511 B in 21s (361 B/s)
Reading package lists...
W: Failed to fetch **ahttps://repo.cubecoders.com/debian/InRelsfsfsdfsfsdfsdfsdfsdfsdfsdfsdfsdfsdfsdfease** Could not handshake: Error in the pull function. [IP: 104.26.0.207 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package ampinstmgr
---------------------------------------------------------------------------------------------------------------------------------
This was gathered from the logs generated by the AMP installation.
Steps to reproduce:
Install Ubuntu server 24.04.1 (the latest one)
sudo apt update to update repos
sudo su -
attempt to install AMP using the installation script - bash <(wget -qO- getamp.sh)
Actions taken to resolve so far:
verify that time/date is correct via timedatectl
run ‘apt update’ - same error as above, ‘Could not handshake: Error in the pull function. [IP: 104.26.0.207 443’
@CubeCoders-Bot could you help this user figure out why they’re having problems fetching from the CubeCoders repo? The repo is being proxied by Cloudflare but this appears to be an isolated issue and not anything systemic. I’ve had them check system time for SSL issues but it’s not that.
Aha, it’s a TLS handshake failure stemming from an “invalid session ID.” Cloudflare can occasionally get a bit picky with connection parameters like this. Classic HTTPS drama. OpenSSL 3.0.x on Ubuntu might not play well with some edge cases in Cloudflare’s config.
Let’s force wget and the repo connection to downgrade the TLS version. Configure this in your machine to avoid the error without compromising general system security:
Create a file for wget configuration:
sudo nano /etc/wgetrc
Add these two lines at the top:
check_certificate = on
secure_protocol = TLSv1_2
Give it another go with the installation script:
bash <(wget -qO- getamp.sh)
Let me know if this gets us talking to the Cubecoders repo properly this time!
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Ugh, stubborn errors are my nemesis. Alright, let’s get creative: we’re going to manually fetch and add CubeCoders’ repo files. Freshly minted shortcuts for drama like this. Follow these steps:
Alright, this rules out an ordinary DNS or repo issue. Since you’re hitting Cloudflare’s edge and the SSL connection itself is failing consistently, this starts to smell like either a network-level problem (your ISP or firewall) or OpenSSL hating life on this system.
A quick check for any blanket TLS issues: Let’s temporarily fall back to HTTP (non-SSL) to determine whether SSL is truly the choke point.
If this works, then the culprit is some SSL/TLS server-client miscommunication. If even HTTP doesn’t work, we’ll look deeper into whether there’s some network-level funny business going on. Let me know the results!
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Ah, yes—apt-key being a diva as it nears its retirement party. No worries; let’s fix that and stick with modern practices. Here’s how you can handle the GPG key:
Yikes, this SSL issue is relentless. Let’s double-check what’s choking this connection.
Test OpenSSL Direct
Run this to manually test the SSL handshake using OpenSSL:
openssl s_client -connect cdn-repo.c7rs.com:443
This will spit out the TLS/SSL negotiation details. If there’s a specific issue with the SSL protocol, ciphers, or certificates, it’ll show up here. Drop the output here (as text), and we’ll dig further.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Oof. That “write:errno=104” means the connection got reset, likely by the server (or potentially Cloudflare). Looks like the SSL handshake isn’t going anywhere—like trying to call a fax machine on your smartphone.
Before we dive into more network-level debugging, let’s double-check some environment setups just to confirm nothing weird is going on locally:
Clear DNS Cache:
Sometimes a stale DNS cache could target the wrong Cloudflare server.
sudo systemd-resolve --flush-caches
Switch DNS Resolver:
If you’re using default ISP resolvers, let’s switch to Google DNS or Cloudflare DNS:
sudo nano /etc/resolv.conf
Replace everything inside with:
nameserver 1.1.1.1 # Cloudflare
nameserver 8.8.8.8 # Google
Save and apply.
Once done, retest a connection to see if the handshake persists:
curl -v https://cdn-repo.c7rs.com/
If the issue stubbornly sticks around, my gut says Cloudflare’s protecting the endpoint too aggressively (or something in your network path is limiting it). If that’s the case, we can try routing through a VPN to see if the issue vanishes when the server’s hit from a different geo-region. Would you have access to one?
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Okay, so the DNS part looks good now, but the SSL connection is still throwing its toys out of the pram with this “illegal parameter” and “invalid session ID” nonsense. This is firmly OpenSSL refusing to play nice with Cloudflare’s edge settings for the CDN.
Here’s the most likely fix:
We’ll manually force curl (which AMP’s installer indirectly uses) to drop to TLSv1.2. Modern GNU/Linux includes support for TLS tweaks using curl built-in flags or OpenSSL environment changes.
Try this:
curl --tlsv1.2 -v https://cdn-repo.c7rs.com/
Does that work smoothly?
If it does, it’s evidently OpenSSL’s default negotiation being too aggressive (jumping straight to TLSv1.3). Post the results back (text not screenshots again, of course!). If this succeeds manually, we’ll override things system-wide for the AMP install process.
This post was produced by an AI controlled by CubeCoders Limited - Feedback
Alright, even explicitly forcing TLSv1.2 is getting smacked down here, meaning Cloudflare is fully rejecting connections from your host. This isn’t just some OpenSSL quirk—it’s a server-side filter in play.
Final Debugging Step:
Let’s completely sidestep the SSL drama and test whether it’s a geographic/network/routing issue. Use a VPN to re-route traffic and retry the connection, or—if a VPN isn’t an option—we can test network-level troubleshooting:
Option 1: Test with curl through a proxy
If you have access to a proxy server or VPN on a different network, set it up:
Ah-ha! The mystery internet saboteur has been unmasked—your ISP is the culprit. What’s likely happening is that the ISP is either meddling with encrypted traffic or has something funky in its routing to Cloudflare that breaks SSL.
Moving forward:
For now, stick with the VPN to complete the AMP installation and setup. At least we know the VPN bypasses the issue entirely.
If you’d rather not rely on the VPN long-term, you may want to call your ISP and ask why they’re blocking or interfering with legitimate HTTPS traffic to Cloudflare endpoints. They’ll probably shrug and say it’s not their fault, but it’s worth a shot for permanent fixes.
Let me know if you hit any further snags during the install. Otherwise, go forth and build your AMP empire!
This post was produced by an AI controlled by CubeCoders Limited - Feedback