Should be working now, I switched it to podman and forgot about the socket. Let me know!
micah
On 2024-03-21 09:21:56, kwadronaut (@kwadronaut) wrote:
kwadronaut created an issue: #154
runner01-sea seems to have a some problem:
ERROR: Failed to remove network for build ERROR: Preparation failed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? (docker.go:933:0s)
I'll move the project that was using it to use another one for now.
-- Reply to this email directly or view it on GitLab: #154 You're receiving this email because of your account on 0xacab.org.
I can make the fallback IP work with the riseup provider, which I probably will do because I'd like to disable the old provider soon.
On 2024-03-05 14:54:22, Kali Kaneko (@kali) wrote:
Kali Kaneko commented on a discussion: #768 (comment 1171018)
I think we still need to remove the IPs - less of a problem, because the fallback should not be used, but they are likely not going to work with float.
- yes, there're harcoded IPs. this was a hack with known limitations.
- those would be used only in the case that DNS resolution fails. So probably hitting the hardcoded IP is masking some other error (perhaps the LE certificate URI).
When I turn up the IP on the new lilypad deployment, clients get this:
2024/03/03 20:32:03 Error fetching eip v3 json:https://api.black.riseup.net/3/config/eip-service.json 2024/03/03 20:32:03 Error again fetching eip v3 json: Post https://198.252.153.107/3/config/eip-service.json: x509: cannot validate certificate for 198.252.153.107 because it doesn't contain any IP SANs
If you retrieve https://api.black.riseup.net/3/config/eip-service.json you will see that it is signed by a valid certificate... but for some reason its trying to connect to the IP directly. When users who are having this problem try to connect to https://api.black.riseup.net/3/config/eip-service.json they are able to get the json without problem.
For some reason, this does work on the old provider.
- this can be deprecated when switching to bitmask-core, since that implements other ways to bypass DNS blocks (DoH, DoT, arbitrary socks5 proxy, obfs4 introducer).
I have to keep the old provider up and running because of this. It would be good to figure out a work-around
On 2024-03-03 21:05:02, Kali Kaneko (@kali) wrote:
Since switching the riseup provider to lilypad, and new infrastructure, some users began to report problems connecting to the api endpoint. Eventually, we discovered it was only desktop clients who had this problem, and the problem was because we had changed the IP of the API endpoint, and it appears that bitmask hard-codes the ip of the provider api endpoint. I think there may be a rationale behind this (such as guarding against DNS problems), but it is a very hidden, tightly coupled, and different mechanism than android uses.
I think this should be revisited, because provider agility around IP addresses is important. Right now riseup has two different ips that resolve for api.black.riseup.net
and those should be able to change (by either adding more, or removing ips) depending on the needs of the provider and not require a code change, release, and roll-out to users of new versions.