s7r wrote:
I have edited /lib/systemd/system/tor@default.service & tor@.service to NoNewPrivileges=no and also installed libcap2-bin and setcap +ep to obfs4proxy executable. The libcap2-bin step is because I want to bind to a lower port, but even if I try to bind to a higher port like 50001 it will still not work and report the same:
Pluggable Transport process terminated with status code 256.
On another server I did a software upgrade from stretch to buster by apt dist upgrade and obfs4proxy stopped working as well. I am still digging here cause there are chances I did some mistakes while upgrading, so I am just mentioning the Bullseye problem because there are no excuses there, it should work, it's a clean fresh new install from scratch.
Can someone please have another look to see if the problem is just on my side or if it's persistent among Bullseye installs, we should update the wiki bridge howto. Thanks.
Hello,
I think it has something to do with our hardening configuration. On Debian Bullseye, I start my bridge with log info and I get:
[info] process_exec(): Starting new process: /usr/local/bin/obfs4proxy [info] launch_managed_proxy(): Managed proxy at '/usr/local/bin/obfs4proxy' has spawned with PID '1856'.
When I start the bridge (using systemd/systemctl), there are no Tor processes or obfs4proxy processes running on the machine.
After it logs that info that it has spawned with another PID, I can find that PID in my system as DEFUNCT.
# ps aux | grep tor debian-+ 1855 91.9 5.7 243532 230668 ? Rs 17:28 0:15 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 debian-+ 1856 5.2 0.0 0 0 ? Z 17:28 0:00 [tor] <defunct>
Wonder what is causing this. I am using the default install from deb.tp.o just with NoNewPrivileges=no to tor@default.service and tor@.service.
I also find it buggy that this is at info level.