search

clostra / newnode_desktop

Desktop client for NewNode VPN. Usable by altrustic nodes.
1 stars 0 forks source link

newnode desktop cannot exec wget #1

Open flyinhome opened 1 year ago

flyinhome commented 1 year ago

repeat by:

snap start newnode_desktop
sleep 5 # wait a bit
https_proxy=http://localhost:8006 wget https://cnn.com

from /var/log/syslog:

Jul 15 17:17:07 wrath newnode-vpn-desktop.nn-vpn-proxy[2231177]: https: https://stats.newnode.com/collect?v=1&tid=UA-149896478-2&t=event&ec=byte_counts&ds=app&ni=1&ea=peer&el=cnn.com&ev=11352&dh=cnn.com&an=client&aid=com.newnode.client
Jul 15 17:17:07 wrath newnode-vpn-desktop.nn-vpn-proxy[2231177]: https_wget: wget https://stats.newnode.com/collect?v=1&tid=UA-149896478-2&t=event&ec=byte_counts&ds=app&ni=1&ea=peer&el=cnn.com&ev=11352&dh=cnn.com&an=client&aid=com.newnode.client -o /dev/null -O /dev/null -T 15
Jul 15 17:17:07 wrath newnode-vpn-desktop.nn-vpn-proxy[2231177]: started wget on pid:2307223 sp:0x12c3500
Jul 15 17:17:07 wrath newnode-vpn-desktop.nn-vpn-proxy[2231177]: do_https (https://stats.newnode.com/collect?v=1&tid=UA-149896478-2&t=event&ec=byte_counts&ds=app&ni=1&ea=peer&el=cnn.com&ev=11352&dh=cnn.com&an=client&aid=com.newnode.client) returning 0x6da4c
Jul 15 17:17:07 wrath newnode-vpn-desktop.nn-vpn-proxy[2307223]: spawn: pid 2307223: cannot exec /root/parts/nn-vpn-proxy/install/usr/bin/wget: No such file or directory
flyinhome commented 1 year ago

I've tried a few things to fix. One problem is that the snap runs in a container that doesn't have access to the entire file system. Another problem is that the location of the wget executable won't be consistent from one version of Linux to another.

flyinhome commented 1 year ago

(logging things I've done to try to fix this here...)

I've tried installing the wget-snap snap and having the NN VPN client execute that executable instead of /usr/bin/wget, but I'm seeing at least two failures from that: 1) often there's already a version of client running that is already bound to port 8006 (even if I stop the snap before starting it); 2) when the client fails, there's an error message "invalid path to external symbolizer"

flyinhome commented 1 year ago

(another update)

I've tried a couple of variations of having this snap treat the wget apt package as a dependency. Problem is, when I do this the shared libraries needed to run wget don't get added to the container that the snap runs in, so the wget executable fails when client tries to exec it. I consider this a bug in snap/snapcraft.

I'm currently looking into writing a https_libevent.c module that would replace https_wget.c. This would avoid the need to fork and exec wget ,and it appears that the new code would be considerably simpler than the old code.