Blocked

[Mcbomb]

Hello, i run docker Image, does Not work. Error "licence run out"

Looked peer2profit deleted the docker reposity

[enwaiax]

Yes, they don't provide official docker image anymore

[dopaemon]

Yes, they don't provide official docker image anymore

may using this repo ?

[enwaiax]

Yes, they don't provide official docker image anymore

may using this repo ?

Doesn't work, either

[apedance]

Software expired.

2023-09-08T09:56:04Z | Error: "Server reply: SOFTWARE EXPIRED"
2023-09-08T09:56:04Z | Error while getting of configuration. Repeat.
2023-09-08T09:56:24Z | Waiting configuration.
2023-09-08T09:56:26Z | Getting configuration is error : Network: HTTP Status failed (1). (backend error:99 cu)
2023-09-08T09:56:26Z | Error: HTTP 423 "Locked"
2023-09-08T09:56:26Z | Error: "Server reply: SOFTWARE EXPIRED"
2023-09-08T09:56:26Z | Error while getting of configuration. Repeat.

[ddscentral]

The old Docker console client will still work if you previously had a peer registered. But it won't work for registering new peers. For new peers, only the new GUI client will work.
I have put together a Docker image for my own use with very barebones Xvnc configuation for running their Linux GUI client. I can share my buildfiles if there's any interest. You have to input your e-mail manually though on first run, I haven't found a way to do this automatically.
Sadly, the new app is only built for x86, no ARM version is available.

[apedance]

I am interested, yeah. Thank you.

[skier789]

Can I share the docker build file of the Linux GUI client? thank you.

The old Docker console client will still work if you previously had a peer registered. But it won't work for registering new peers. For new peers, only the new GUI client will work. I have put together a Docker image for my own use with very barebones Xvnc configuation for running their Linux GUI client. I can share my buildfiles if there's any interest. You have to input your e-mail manually though on first run, I haven't found a way to do this automatically. Sadly, the new app is only built for x86, no ARM version is available.

Can I share the docker build file of the Linux GUI client? thank you.

[ddscentral]

You can download the Docker scripts here.

How to use:

• Extract the archive.
• cd peer2profit-gui
• To build, type ./install.sh
• To run, type ./peer2profit.sh
• Connect your VNC client to port 5950 (password: netshare) and enter your email into the GUI client.

After entering your email, the client will minimize itself. There's no way to bring it back from the VNC. To bring it back up to view, run ./bringup.sh
I made these files for my own internal use, so there's no README of any kind inside. You can tweak VNC ports, password, etc. by editing the files.
The GUI client is built for x86 only, to run this on non-x86 systems, you will need a translation layer, like this. You will also need to make changes to install.sh to cross-build the image to linux/amd64.

[joaquinbvw]

You can download the Docker scripts here.

How to use:

• Extract the archive.
• cd peer2profit-gui
• To build, type ./install.sh
• To run, type ./peer2profit.sh
• Connect your VNC client to port 5950 (password: netshare) and enter your email into the GUI client.

After entering your email, the client will minimize itself. There's no way to bring it back from the VNC. To bring it back up to view, run ./bringup.sh I made these files for my own internal use, so there's no README of any kind inside. You can tweak VNC ports, password, etc. by editing the files. The GUI client is built for x86 only, to run this on non-x86 systems, you will need a translation layer, like this. You will also need to make changes to install.sh to cross-build the image to linux/amd64.

Thank you so much! I was trying to run the docker too for a while on new devices. Although, weirdly enough, I have one docker still running on a VPS, it's very weird because it died on my other VPS. By the way do you know if this can run on a Raspberry Pi too? I know how to the architecture emulation, is that enough? Thanks again!

[joaquinbvw]

So I have built and run @ddscentral 's docker on the Raspberry Pi 4. I used the same container for architecture emulation (amd64) recommended by @ddscentral , it's actually very easy to set it up. Then I did some small changes on the scripts, on the install.sh file I changed it to this:

docker buildx build -t netshare/peer2profit --platform=linux/amd64 .

And on the peer2profit.sh file I changed it to this:

docker rm -f peer2profit || true && docker run --platform linux/amd64 -d --restart unless-stopped -p 5950:5900 \
--name peer2profit \
netshare/peer2profit
echo "Now connect to VNC on port 5950 with password 'netshare' and setup the client."

It was built and it runs, it took a while to build though, so I'm not sure if it is working as it should. Also I can see it with no problems on the VNC viewer and the bringup.sh script is also working great. The only issue is that the gui says that it is connected but when I see it on Telegram it shows as offline so I'm not sure if it's working at all. I have ufw enabled so maybe I need to change something on it? Maybe to open ports in some way? I'm not sure yet how to proceed. I will try disabling ufw and restarting the container. It would be great to have some sort of log also, not sure if the gui generates log files. Please let me know if you have any idea on what to do. I will update it when I have anything working.

[ddscentral]

It took a while to build because the build is done using amd64 userspace, all binaries run through QEMU emulation.
It is technically possible to spin-up a "hybrid" image with arm64 userspace and VNC. Currently I have no need for this but should I write a Dockerfile for arm64, I'll upload it to the same "proxywares" directory.

I have never tested this new GUI client under QEMU, so I'm not sure if it works properly. The binary does output some logs (mostly Qt stuff), do check docker logs to see if there's anything.
Firewall should not be an issue if internet access works fine, but it wouldn't hurt to disable it temporarily for testing purposes.

[joaquinbvw]

It took a while to build because the build is done using amd64 userspace, all binaries run through QEMU emulation. It is technically possible to spin-up a "hybrid" image with arm64 userspace and VNC. Currently I have no need for this but should I write a Dockerfile for arm64, I'll upload it to the same "proxywares" directory.

I have never tested this new GUI client under QEMU, so I'm not sure if it works properly. The binary does output some logs (mostly Qt stuff), do check docker logs to see if there's anything. Firewall should not be an issue if internet access works fine, but it wouldn't hurt to disable it temporarily for testing purposes.

Thanks for the reply. So it hasn't go online since 12 hours so I guess it's not working with QEMU at the moment. I tried looking into the logs from docker but it just shows me the VNC information, it doesn't show anything from peer2profit. When you run this app on a linux desktop does it generate any logs? If I know the location maybe I can make them watchable from the docker or something like that, just to see what's going on. On the other hand, I have tried your docker on a VPS and it worked perfectly.

I also would want to try something like cross compilation like this, but I'm not familiar with it so I don't know if it will work. I will be playing with that later today.

[MRColorR]

i have the same problem on a different image. I'd like to help fix this behaviour on arm64.
my findings so far are:

• an x64 image will work as expected if running on a docker x64 machine, after some time in the dashboard the node will go from gray to green, IP information is populated correctly in the dashboard
• on an arm64 device using the binfmt emulation layer the same x64 image will boot (GUI appears and email is accepted, login successful) but then in the dashboard the node will remain grey, no IP information.

so the problem could be one or more of these things:

• maybe the binfmt emulation layer causes problems at the network level
• maybe the peer2profit app can detect that it's running inside an emulation layer and doesn't proceed after login
• maybe the peer2profit app can detect that it's running on a different architecture and doesn't proceed after login

[ddscentral]

Most likely it's an app compatibility issue with QEMU.
After login, P2P GUI spawns a secondary background process for proxying with an auth token as a parameter. When emulating using binfmt_misc, this secondary process either never launches or crashes instantly.
The IP does show up sometimes in the dash, never with a green status though.

[1RandomDev]

The old Docker console client will still work if you previously had a peer registered. But it won't work for registering new peers. For new peers, only the new GUI client will work. I have put together a Docker image for my own use with very barebones Xvnc configuation for running their Linux GUI client. I can share my buildfiles if there's any interest. You have to input your e-mail manually though on first run, I haven't found a way to do this automatically. Sadly, the new app is only built for x86, no ARM version is available.

You don't need to input the email address in the GUI, just put the following in the file ~/.config/org.peer2profit.peer2profit.ini:

[General]
StartOnStartup=true
Username=<email>
hideToTrayMsg=true
installid2=<random uuidv4>
locale=en_US

I have now created an image that runs the new Peer2Profit client completely headless with xvfb and automatically applies the configuration from environment variables https://github.com/1RandomDev/peer2profit-gui

[enwaiax]

Fixed. Thank @1RandomDev provided the solution

[joaquinbvw]

Fixed. Thank @1RandomDev provided the solution

It still doesn't work on arm64. By the way @1RandomDev solution is great! I will replace the container I'm running right now with the GUI with this one later. Regarding arm64 I just ran this new container with qemu and the result is the same as always. I'm wondering if using box64 would be more effective... maybe I will try that on the following weeks.

[enwaiax]

@joaquinbvw arm is not supported anymore

[MRColorR]

Most likely it's an app compatibility issue with QEMU.
After login, P2P GUI spawns a secondary background process for proxying with an auth token as a parameter. When emulating using binfmt_misc, this secondary process either never launches or crashes instantly.
The IP does show up sometimes in the dash, never with a green status though.

Could you tell me how you found this info? I'd like to dwell more into it to find what's going wrong between quemu and this process

[ddscentral]

@MRColorR By comparing the behavior of the app when running my container natively on amd64 and on arm64 via qemu-user. On amd64, a second process is started with what looks like an auth token passed as a parameter.
When running on arm64 via qemu-user, this never happens, only the initial GUI process runs.

[MRColorR]

@MRColorR By comparing the behavior of the app when running my container natively on amd64 and on arm64 via qemu-user. On amd64, a second process is started with what looks like an auth token passed as a parameter. When running on arm64 via qemu-user, this never happens, only the initial GUI process runs.

i'm still researching abouth this as i'd like to make it compatible with arm again and currently i'd liike to capture the error logs of the spawining and spawned process you were taliking about .

Maybe you already know but i've found some info about the dependecies of pee2profit deb

• Depends: libxcb-glx0, libx11-xcb1, libxcb-icccm4, libxcb-image0, libxcb-shm0, libxcb-keysyms1, libxcb-randr0, libxcb-render-util0, libxcb-sync1, libxcb-xfixes0, libxcb-render0, libxcb-shape0, libxcb-xinerama0, libxcb-xkb1, libxcb1, libx11-6, libxkbcommon-x11-0, libxkbcommon0, libgl1, libxcb-util1, libxau6, libxdmcp6, libbs.

you can see more infos in the following repo where the deb package has been opened: https://github.com/goastler/peer2profit/blob/main/peer2profit_0.48_amd64/control/control

[joaquinbvw]

@MRColorR By comparing the behavior of the app when running my container natively on amd64 and on arm64 via qemu-user. On amd64, a second process is started with what looks like an auth token passed as a parameter. When running on arm64 via qemu-user, this never happens, only the initial GUI process runs.

i'm still researching abouth this as i'd like to make it compatible with arm again and currently i'd liike to capture the error logs of the spawining and spawned process you were taliking about .

Maybe you already know but i've found some info about the dependecies of pee2profit deb

* Depends: libxcb-glx0, libx11-xcb1, libxcb-icccm4, libxcb-image0, libxcb-shm0, libxcb-keysyms1, libxcb-randr0, libxcb-render-util0, libxcb-sync1, libxcb-xfixes0, libxcb-render0, libxcb-shape0, libxcb-xinerama0, libxcb-xkb1, libxcb1, libx11-6, libxkbcommon-x11-0,  libxkbcommon0,  libgl1, libxcb-util1, libxau6, libxdmcp6, libbs.

you can see more infos in the following repo where the deb package has been opened: https://github.com/goastler/peer2profit/blob/main/peer2profit_0.48_amd64/control/control

It's great you are still researching how to run it on arm64, I'm mostly a user level guy on docker and don't know much on how qemu works but if you need any help please let me know. I have a bunch of raspberry pis and orange pis to do some testing if you want.

Another thing I was wondering was if maybe there is a way of running the deb package on box64 or wine, I also decompressed the deb file and found those dependencies.

[ddscentral]

i'm still researching abouth this as i'd like to make it compatible with arm again and currently i'd liike to capture the error logs of the spawining and spawned process you were taliking about .

AFAIK there are no logs, apart from what Qt (app's UI framework) initially outputs. But from what I can see, the app does register on the network as I can see a new peer in the list after entering my email. Tried low-level tracing but did not capture any attempts to start a new process.

[MRColorR]

i'm still researching abouth this as i'd like to make it compatible with arm again and currently i'd liike to capture the error logs of the spawining and spawned process you were taliking about .

AFAIK there are no logs, apart from what Qt (app's UI framework) initially outputs. But from what I can see, the app does register on the network as I can see a new peer in the list after entering my email. Tried low-level tracing but did not capture any attempts to start a new process.

Did you try to start the process passing x86_64 as arch with the setarch command ?

[ddscentral]

It's great you are still researching how to run it on arm64, I'm mostly a user level guy on docker and don't know much on how qemu works but if you need any help please let me know. I have a bunch of raspberry pis and orange pis to do some testing if you want.

Another thing I was wondering was if maybe there is a way of running the deb package on box64 or wine, I also decompressed the deb file and found those dependencies.

Wine is for Windows binaries, not relevant for us. But box64 I'd say is worth trying out. I will take a loot at it.

[ddscentral]

Did you try to start the process passing x86_64 as arch with the setarch command ?

I have tried both making the whole container run through qemu-user-x86_64 (tonisitiigi/binfmt) and integrating the qemu-user-x86_64 binary into an ARM64 based image (with multiarch and some x86 dependencies to make the app happy). Apart from the whole container emulation being much slower, there was no difference in app's behavior.

[ddscentral]

box64 appears to work. The UI is much more responsive and the second process now runs correctly. But the peer gets banned for some reason, maybe they're no longer allowing multiple peers per IP. Trying to get it unbanned by disabling the other peer on the same IP, will see if this works.
If I can confirm it works, I will make a repo with build files.

[ddscentral]

Well, initially it was promising. But nothing useful came out of it. This time, the client connects but always gets banned with "Provider". Manually running the client with "-e <token>" does output a bit of log but nothing useful. There are no box64 crashes or errors reported.
Attempting to use a "good" installid2 in the .ini file just results in a peer that's always stuck with "grey" status.
As an experiment, tried running the client directly with box64 (no Docker), same result.
I'm not willing to spend anymore time on this. Sorry guys.

There's little point in posting the Dockerfile since it's a mess up from all the debugging, etc. Basically, it involves installing box64 plus dependency packages listed in peer2profit .deb. Then, you need to extract the client binary from .deb file and copy it over to /usr/bin/. Installing the .deb. in multiarch also works if you want to go that way.
To run the client, use command "/usr/bin/box64 /usr/bin/peer2profit".

[MRColorR]

Well, initially it was promising. But nothing useful came out of it. This time, the client connects but always gets banned with "Provider". Manually running the client with "-e <token>" does output a bit of log but nothing useful. There are no box64 crashes or errors reported.
Attempting to use a "good" installid2 in the .ini file just results in a peer that's always stuck with "grey" status.
As an experiment, tried running the client directly with box64 (no Docker), same result.
I'm not willing to spend anymore time on this. Sorry guys.

There's little point in posting the Dockerfile since it's a mess up from all the debugging, etc. Basically, it involves installing box64 plus dependency packages listed in peer2profit .deb. Then, you need to extract the client binary from .deb file and copy it over to /usr/bin/. Installing the .deb. in multiarch also works if you want to go that way.
To run the client, use command "/usr/bin/box64 /usr/bin/peer2profit".

Thanks for your time and effort.
So they do not accept any virtualization or emulation anymore and I cannot find a way to workaround this...they put lots of effort to make it this way. So if it works they ban it, if it doesn't...well that's good for them as it seems 🤷‍♂️.

[ddscentral]

They don't block virtualization or Docker. All my peers run inside Docker containers running on VMs.
It could be either a bug in box64 or P2P actively trying to detect emulation. It's hard to tell without spending countless more hours debugging. Which I'm not willing to do, as mentioned before.

Interestingly, the Linux client is gone from the P2P bot's download list. Now there's just macos and Android. Link still works though.

[joaquinbvw]

They don't block virtualization or Docker. All my peers run inside Docker containers running on VMs. It could be either a bug in box64 or P2P actively trying to detect emulation. It's hard to tell without spending countless more hours debugging. Which I'm not willing to do, as mentioned before.

Interestingly, the Linux client is gone from the P2P bot's download list. Now there's just macos and Android. Link still works though.

Oh no that's a shame. Thanks for the work anyway! What if we try with the APK file from Android? I read the other day that there is a way to emulate an apk on docker, I will try to do some research about it.

Also I remember a while ago they ban a device of mine when I tried to install the docker container twice with same IP, is there a chance this was your case maybe?

I will try going through the apk path to see if there is a chance.