Debian 9 and PIA client
Has anyone found a way to make the PIA client work with Debian 9 / Cinnamon? So far I haven't had any luck with that or the other work arounds I've found online. I migrated to Debian from Mint (where the client worked flawlessly) and even though Mint is a child of Debian, we all know there's a difference between Debian and all the "kids". LOL
Comments
-------------------------------------begin included strace------------------------------------------------
[email protected]:~/.pia_manager$ ./pia_manager/run.sh
pia_nw: no process found
kill: (4410): No such process
[email protected]:~/.pia_manager$ man strace
No manual entry for strace
[email protected]:~/.pia_manager$ man strace
[email protected]:~/.pia_manager$ strace ./pia_manager/run.sh
execve("./pia_manager/run.sh", ["./pia_manager/run.sh"], [/* 56 vars */]) = 0
brk(NULL) = 0x561cd78b8000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3c6506c000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=117922, ...}) = 0
mmap(NULL, 117922, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f3c6504f000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\3\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1689360, ...}) = 0
mmap(NULL, 3795360, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f3c64aad000
mprotect(0x7f3c64c42000, 2097152, PROT_NONE) = 0
mmap(0x7f3c64e42000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7f3c64e42000
mmap(0x7f3c64e48000, 14752, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f3c64e48000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f3c6504d000
arch_prctl(ARCH_SET_FS, 0x7f3c6504d700) = 0
mprotect(0x7f3c64e42000, 16384, PROT_READ) = 0
mprotect(0x561cd708b000, 8192, PROT_READ) = 0
mprotect(0x7f3c6506f000, 4096, PROT_READ) = 0
munmap(0x7f3c6504f000, 117922) = 0
getpid() = 4892
rt_sigaction(SIGCHLD, {sa_handler=0x561cd6e81ef0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f3c64ae0030}, NULL, 8) = 0
geteuid() = 1000
brk(NULL) = 0x561cd78b8000
brk(0x561cd78d9000) = 0x561cd78d9000
getppid() = 4890
stat("/home/jrredho/.pia_manager", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
open("./pia_manager/run.sh", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10) = 10
close(3) = 0
fcntl(10, F_SETFD, FD_CLOEXEC) = 0
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x561cd6e81ef0, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f3c64ae0030}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f3c64ae0030}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTORER, sa_restorer=0x7f3c64ae0030}, NULL, 8) = 0
read(10, "#!/bin/sh\n\nif [ \"$(uname -m)\" = "..., 8192) = 204
pipe([3, 4]) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3c6504d9d0) = 4893
close(4) = 0
read(3, "x86_64\n", 128) = 7
read(3, "", 128) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4893, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
rt_sigreturn({mask=[]}) = 0
close(3) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 4893
pipe([3, 4]) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3c6504d9d0) = 4894
close(4) = 0
read(3, "./pia_manager\n", 128) = 14
read(3, "", 128) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4894, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
rt_sigreturn({mask=[]}) = 0
close(3) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 4894
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3c6504d9d0) = 4895
wait4(-1, pia_nw: no process found
kill: (4491): No such process
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 4895
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4895, si_uid=1000, si_status=0, si_utime=5, si_stime=0} ---
rt_sigreturn({mask=[]}) = 4895
read(10, "", 8192) = 0
exit_group(0) = ?
+++ exited with 0 +++
[email protected]:~/.pia_manager$
-------------------------------------end included strace------------------------------------------------
Good luck sorting this out!
john
i see:
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3c6504d9d0) = 4893
close(4) = 0
read(3, "x86_64\n", 128) = 7
read(3, "", 128) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4893, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
rt_sigreturn({mask=[]}) = 0
close(3) = 0
then:
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f3c6504d9d0) = 4894
close(4) = 0
read(3, "./pia_manager\n", 128) = 14
read(3, "", 128) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4894, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
rt_sigreturn({mask=[]}) = 0
close(3)
and:
wait4(-1, pia_nw: no process found
kill: (4491): No such process
are there files named "x86_64", "pia_manager", and "pia_nw" ? the first two 'stanzas' show child processes being created and ultimately exiting (process IDs 4893 and 4894, respectively). The third stanza seems to indicate there should be a process (code is expecting it) but the process has finished too quickly or crashed.
I'm not that savvy about system calls, etc, but I do have a fresh Debian 9.1 system that I'm happy to exercise to help sort all of this out.
So, before I answer your questions, let me mention that I installed a menu editor, alacarte, and found the PIA app's command line to be: /home/jrredho/.pia_manager/pia_manager/run.sh. So I ran this from a Bash subshell with debugging on. I think you'll find that the output answers a couple of your questions:
--------------------------------------------begin included text------------------------------------------------------
[email protected]:~/.pia_manager/pia_tray_bin/nw-linux-64$ bash -xv /home/jrredho/.pia_manager/pia_manager/run.sh#!/bin/sh
if [ "$(uname -m)" = "x86_64" ]; then
ARCH=64
else
ARCH=32
fi
++ uname -m
+ '[' x86_64 = x86_64 ']'
+ ARCH=64
DIR="$(dirname $0)"
++ dirname /home/jrredho/.pia_manager/pia_manager/run.sh
+ DIR=/home/jrredho/.pia_manager/pia_manager
ARCHDIR="$DIR/$ARCH"
+ ARCHDIR=/home/jrredho/.pia_manager/pia_manager/64
LD_LIBRARY_PATH="$ARCHDIR" "$ARCHDIR/ruby" -I "$DIR" -I "$ARCHDIR" "$DIR/run.rb" "[email protected]"
+ LD_LIBRARY_PATH=/home/jrredho/.pia_manager/pia_manager/64
+ /home/jrredho/.pia_manager/pia_manager/64/ruby -I /home/jrredho/.pia_manager/pia_manager -I /home/jrredho/.pia_manager/pia_manager/64 /home/jrredho/.pia_manager/pia_manager/run.rb
pia_nw: no process found
kill: (1663): No such process
[email protected]:~/.pia_manager/pia_tray_bin/nw-linux-64$
--------------------------------------------end included text------------------------------------------------------
Does that help?
john
you can see exactly the command line to duplicate manually what run.sh is doing when it fires off the Ruby script. try that..
--------------------------------------------begin included text------------------------------------------------------
[email protected]:~/.pia_manager/pia_manager$ /home/jrredho/.pia_manager/pia_manager/64/ruby -w -v -I /home/jrredho/.pia_manager/pia_manager -I /home/jrredho/.pia_manager/pia_manager/64 /home/jrredho/.pia_manager/pia_manager/run.rb
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]
/home/jrredho/.pia_manager/pia_manager/run.rb:2: warning: literal in condition
/home/jrredho/.pia_manager/pia_manager/pia_common.rb:2: warning: literal in condition
/home/jrredho/.pia_manager/pia_manager/pia_common.rb:326: warning: method redefined; discarding old blank?
/home/jrredho/.pia_manager/pia_manager/pia_common.rb:40: warning: previous definition of blank? was here
/home/jrredho/.pia_manager/pia_manager/pia_common.rb:332: warning: method redefined; discarding old blank?
/home/jrredho/.pia_manager/pia_manager/pia_common.rb:46: warning: previous definition of blank? was here
pia_nw: no process found
kill: (4979): No such process
--run
[email protected]:~/.pia_manager/pia_manager$ /usr/bin/ruby -w -v
ruby 2.3.3p222 (2016-11-21) [x86_64-linux-gnu]
[email protected]:~/.pia_manager/pia_manager$
--------------------------------------------end included text------------------------------------------------------
Better? Oh, and I added the version from the system-installed version of ruby just to see if we're encountering a system version/library mismatch.
john
When All Else Fails
Good luck to anyone who's interested in sorting things out...
cheers,
john
I don't know much about Ruby, so I'm not going to be very helpful here. But the "run.rb" seems to be protected and read by some kind of loader. Which makes me wonder if it's even possible to debug.
What I can say is that this output:
pia_nw: no process found
kill: (4979): No such process
may not be part of our problem, as the same output is given on a working system (tested on Ubuntu 17.04)
Here is the result of "strace -r ./64/ruby -I . -I ./64 ./run.rb" which gives a little more information than in the previous comments. I hope it helps to dig a little more.
https://pastebin.com/4VKjFP4P
Now if we are really serious about our privacy, we are not going to use a proprietary software to connect to a VPN, are we? This does not make any sense to me. The source code should be available, there is no reason for this program not to be open source.
log is pretty boring until
line 156: pipe([3, 4]) = 0
236: open("/home/sXXXXn/.pia_manager/pia_manager/64/rubygems.rb", O_RDONLY) = 5
293: open("/home/sXXXXn/.pia_manager/pia_manager/64/rbconfig.rb", O_RDONLY) = 5
419: open("/home/sXXXXn/.pia_manager/pia_manager/64/rubygems/custom_require.rb", O_RDONLY) = 5
494: open("./run.rb", O_RDONLY) = 5
495: read(5, "# RubyEncoder v2.0\n_d = _d0 = Fi"..., 1024) = 1024
529: open("/home/sXXXXn/.pia_manager/pia_manager/pia_common.rb", O_RDONLY) = 5
709: wait4(30844, pia_nw: aucun processus trouvé
738: wait4(30846, kill: (30770): Aucun processus de ce type
749: open("/home/sXXXXn/.pia_manager/log/pia_manager_loop.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
753: write(5, "30842", 5) = 5
there's more to be learned about processes created. the PIDs will be similar to 30842 in this log.
"strace -o debug -ff ./64/ruby -I . -I ./64 ./run.rb"
Dumped all of it to pastebin:
PID 6572 : https://pastebin.com/NcPispGr
PID 6573 : https://pastebin.com/4hHZ6jpT
PID 6574 : https://pastebin.com/hMkRM5T8
PID 6575 : https://pastebin.com/qh08bL8P
PID 6576 : https://pastebin.com/aM5nQYLT
PID 6577 : https://pastebin.com/6J9h4V8W
PID 6578 : https://pastebin.com/T5myX6M2
PID 6579 : https://pastebin.com/PZ26bszp
PID 6580 : https://pastebin.com/6B9HRX3t
PID 6581 : https://pastebin.com/UeywL1J5
PID 6582 : https://pastebin.com/VCWUuKBm
PID 6583 : https://pastebin.com/icjwwyPr
I also attached to this post, a zip containing all the files. It's probably more convenient.
I guess it's time for me to learn more about syscalls
open, close, read, write, pipe getuid, getgid, getpid fork|clone, wait|wait4
PID 6572 fires off some other processes, which all return via wait4().
(it will be some time to work through that list)
PID 6576 as a first act kills PID 6551 (what was that?) via /bin/kill and then later does the same again with a kill() system call. that's kinda weird.
I did some experiments and found out that the process being killed here is the one stored in the file "~/.pia_manager/log/pia_manager_loop.pid".
It is also the one mentioned in the standard output:
kill: (<PID HERE>): No such process
It is apparently killing any running instance of pia_nw. I feel like the whole program is about kill that process
edit: wait, my last statement is wrong, this process is not pia_nw, it is the ID of the main process when it was last executed. You can see when it is stored to the log file at line 752 of PID 6572 strace log.
PID 6581 appears to return the full name of the pia installation directory
PID 6582 looks for some files which seem important, but doesn't find them operating_system.(rb|so) && ruby.(rb|so) .. it's possible other files have been sought but not found -- you look (use grep) in the other strace files to confirm. looks for and doesn't find zlib.rb and also doesn't find libz.so.1 (probably very important -- oh! nevermind. it finds system library libz.so.1 instead). ah! libssl.so.1.0.0 wanted but not found. specification.(rb|so) no joy. it writes to .pia_manager_crash.log (has anyone looked in there for clues?). then it exits.
^^ read carefully. examine interesting things.
I didn't see a crash log was created !
Here is the content of the crash log file:
Starting from here, the first objective seems to get that specification.rb file to the right place.
https://www.privateinternetaccess.com/forum/discussion/23261/desktop-applications-release-v66
The specification.rb file does exist and can be found in this folder:
/usr/lib/ruby/2.3.0/rubygems
and same for the .so file ..
This gives me a different error in the crash log:
#<NameError: uninitialized constant Gem::Specification>
What do you think about using a clean install of ruby 1.9.1 rather than the one packaged with the application?
I'm trying to build ruby 1.9.1 without success so far. I will let you know when I get ruby installed if that helps.
ps: it was worth a try to make the link but now i'm more certain specification.so is necessary.
If you have suggestions, I will happily try them, but this is becoming time consuming so I will stop trying to investigate.
I hope the devs are going to take care of this issue, or at least release the source code, which would make a lot of sense. I still don't get the point of hiding it.
Thank you martouf, I learnt a lot in the process!
they might not be hiding the code from you, the client, as much as they are hiding it from them, the competitor.
did you find
https://wiki.debian.org/Ruby
and use it as a guide?
because that leads almost directly to
https://packages.debian.org/search?keywords=ruby1.9.3
which, being a 1.9.x release should be sufficient.
but if you want to version-match exactly, there is
https://packages.debian.org/search?keywords=ruby1.9.1