bug: Issues in installing on MacOS

[francescomiliani]

What happened?

Hello, we experimented issues during installation on MacOS, whose conducts to errors on access it via the web.

What did you expect to happen?

A correct working

How can we reproduce it (as minimally and precisely as possible)?

By installing Paladin on MacOs with version specified in OS Version section

Anything else we need to know?

Attached logs
logs.zip

OS version

Hello,

Installing the software on Windows using the following link,
https://lf-decentralized-trust-labs.github.io/paladin/head/getting-started/installation/#outcome
we did not encounter any issues. However, on Mac OS, after the installation, we were unable to access it via the web.
The configuration is :
macOS Monterey Versione 12.1
MacBook Pro (Retina, 13-inch, Early 2015)
Processor 2,9 Ghz Intel Core i5 dual-core
Memory : 8 GB 1867 Mhz DDR3

In attachment the logs file

The Pod verification command produces the following outputs:

Kubectl get pods

Kubectl get service

Kubectl get scd

Kubectl get reg

The web access remains pending indefinitely

Also with curl

[hosie]

Hi @francescomiliani do you see the same issue with all paladin nodes? did you try http://localhost:31648/ui or http://localhost:31748/ui

[gabriel-indik]

@francescomiliani are you able to access the JSON RPC API? Specifically, if you use the POST method against http://127.0.0.1:31548 (without a body or any other arguments), do you see the following?

{
    "jsonrpc": "2.0",
    "id": "1",
    "error": {
        "code": -32600,
        "message": "PD020700: Invalid JSON/RPC request data"
    }
}

[francescomiliani]

Hi @francescomiliani do you see the same issue with all paladin nodes? did you try http://localhost:31648/ui or http://localhost:31748/ui

Hi @hosie, thank you for your reply. Below I attached screenshots taken from Chrome Browser

[francescomiliani]

@francescomiliani are you able to access the JSON RPC API? Specifically, if you use the POST method against http://127.0.0.1:31548 (without a body or any other arguments), do you see the following?

{
    "jsonrpc": "2.0",
    "id": "1",
    "error": {
        "code": -32600,
        "message": "PD020700: Invalid JSON/RPC request data"
    }
}

Hi @gabriel-indik, thank you for your reply.

Here the result executed with Postman

here a telnet on path suggested

[hosie]

Current suspicion is that something is not quite right in the docker and/or kind networking layer. The 31548 on local host should be an open node port on your kind cluster and the internal k8s networking should be routing that to you paladin node pod via the defined svc. If the port was not opened, we would expect connection refused rather than a hang. If you could run docker ps docker info and kind version and kubectl get svc -n paladin it might show something. Would be particularly interested to see, from that output, which versions of docker and kind you have.

Another thing to try, just to rule out a problem with the container itself. If you exec into one node ( e.g. kubectl -it exec paladin-node1-0 -- /bin/sh) and try to connect to another node curl http://paladin-node2:8548. you should see

{"jsonrpc":"2.0","id":"1","error":{"code":-32600,"message":"PD020700: Invalid JSON/RPC request data"}}

[francescomiliani]

Current suspicion is that something is not quite right in the docker and/or kind networking layer. The 31548 on local host should be an open node port on your kind cluster and the internal k8s networking should be routing that to you paladin node pod via the defined svc. If the port was not opened, we would expect connection refused rather than a hang. If you could run docker ps docker info and kind version and kubectl get svc -n paladin it might show something. Would be particularly interested to see, from that output, which versions of docker and kind you have.

Another thing to try, just to rule out a problem with the container itself. If you exec into one node ( e.g. kubectl -it exec paladin-node1-0 -- /bin/sh) and try to connect to another node curl http://paladin-node2:8548. you should see

{"jsonrpc":"2.0","id":"1","error":{"code":-32600,"message":"PD020700: Invalid JSON/RPC request data"}}

Hi @hosie, thanks again, here commands and outputs:

Docker PS

docker info
Client:
Version: 25.0.3
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.1-desktop.4
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.24.6-desktop.1
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-compose
debug: Get a shell into any image or container. (Docker Inc.)
Version: 0.0.24
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-debug
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.22
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-extension
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.4
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-feedback
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.0.1
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-sbom
scout: Docker Scout (Docker Inc.)
Version: v1.5.0
Path: /Users/siaeasyshop/.docker/cli-plugins/docker-scout

Server:
Containers: 2
Running: 2
Paused: 0
Stopped: 0
Images: 1
Server Version: 25.0.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ae07eda36dd25f8a1b98dfbf587313b99c0190bb
runc version: v1.1.12-0-g51d5e94
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
cgroupns
Kernel Version: 6.6.16-linuxkit
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 3.825GiB
Name: docker-desktop
ID: f6216e93-9795-4347-bfc8-619ea2450ab9
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false

WARNING: daemon is not using the default seccomp profile

Kind version

kubectl get svc -n paladin

kubectl -it exec paladin-node1-0 -- /bin/sh
curl http://paladin-node2:8548/

Thanks again for your support

[hosie]

Thanks @francescomiliani the only things I can see that are significantly different from my env is

• the version of docker. I have Server Version: 27.2.0
• resources available to docker. I have CPUs: 10 and Total Memory: 15.6GiB.
• arch. I have Architecture: aarch64

I am pretty sure that it should not need 10CPU and 15GiB of memory but maybe worth increasing your resources in docker desktop to see if it makes a difference. and/or check whether your docker desktop has any pending updates.

In the meantime, I'll see if I can find anyone else who has tested on x86 Mac. Could you run uname -a to confirm the version and arch of your host OS?

[francescomiliani]

Hi @hosie, here my uname -a output

Darwin MacBook-Pro-di-Sviluppo.local 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:28:54 PST 2021; root:xnu-8019.61.5~1/RELEASE_X86_64 x86_64

We might update Docker, for instance, or could be a problem related to kind?

[hosie]

@francescomiliani

I do know of one other person who has been using the same kind version as you without issue but I do not know of anyone who has been using x86 on Mac.

How persistent is this problem for you? e.g. if you restart the pods ( kubectl delete paladin-node1-0) or restart the kind cluster / or even delete it kind delete cluster --name paladin and follow the getting started instructions from scratch, do you still see the same issue?

[francescomiliani]

@hosie
It seems we solved the problem 😎

We did the following steps:

1. Reinstalled kind via binary: we installed kind via brew. So, we uninstalled it and re-installed it via downloading the binary and moving it under /Applications, and updating the bash_profile.
   Here the guide: kind

2. Updated Docket to : Docker version 27.3.1, build ce12230

Thank you for your support :)

[hosie]

That's great news @francescomiliani . Thank you for persisting with it.