[enhancement] Autorun on boot

[acameraman]

Would have to keep in mind that OpenVPN creates an initscript during installation that scans for .conf configuration files in /etc/openvpn, and if found, starts up a separate OpenVPN daemon for each one.

Finding a way to define env. variables like how you can input them in the command to start ./get_region_and_token.sh would take care of needing user inputs during server selection.

[g00nix]

Sorry for not answering for 16 days. Every time I look at this ticket, I get confused regarding how to proceed. I feel like having autorun on boot is a bit out of the scope of this repository, mostly due to the fact that people can have various init systems and they could also just run the scripts in containers.

I think the best way to move forward is to create a service for your init system and to inject the variables into the scripts (with the supported method for your system), or to fork and modify the scripts so that they satisfy your requirements.

[JeffreyShran]

@g00nix I was wondering if a simple solution to this is to alter run_setup.sh so that it accepts the variables as input parameters. Then users can just add something like this into their cron:

@reboot bash ~/pia-foss/manual-connections/run_setup.sh -user abc123 -pass p123 -conn w

The script can still be verbose for general use as it is now and to allow 'background' usage we could say that if a parameter was provided then the "PIA username (pNNNNNNN):" stuff doesn't need to be displayed.

A simple log file option could be used so that users can catch the output from the scripts to a central location of their choosing.

I think that this could be achieved without adding too much complication and removes the need for a load of customisation per user system?

[g00nix]

@JeffreyShran did you have a look at get_region_and_token.sh?

[JeffreyShran]

thanks

[g00nix]

thanks

This will change in v2.0.0. We are going to reorganize the scripts and the env vars will also be added to run_setup.sh. The reason we are using env vars instead of parameters is because env vars became a best practice with the globalization of docker. At this point, get_region_and_token.sh is doing most of the heavy lifting and we need to split that into get_region and get_token so that people can use individual scripts for different scopes. So don't get to used to the current setup, or please automate using the tag version and not just the master branch. You cat have a look at the v2.0.0 preview if you are curious, but it is still under construction.

Regarding running this on boot, I think the best way is to extend the documentation with tips on how to run this on boot with systemd, however not for any other init system (just because there are to many). I do understand that most people have systemd and most people want to run this at boot.

I think we will have to wait till v2.0.0 is ready for public use, and after that use it as a foundation to add more features on top.

[cbc02009]

thanks

This will change in v2.0.0. We are going to reorganize the scripts and the env vars will also be added to run_setup.sh. The reason we are using env vars instead of parameters is because env vars became a best practice with the globalization of docker. At this point, get_region_and_token.sh is doing most of the heavy lifting and we need to split that into get_region and get_token so that people can use individual scripts for different scopes. So don't get to used to the current setup, or please automate using the tag version and not just the master branch. You cat have a look at the v2.0.0 preview if you are curious, but it is still under construction.

Regarding running this on boot, I think the best way is to extend the documentation with tips on how to run this on boot with systemd, however not for any other init system (just because there are to many). I do understand that most people have systemd and most people want to run this at boot.

I think we will have to wait till v2.0.0 is ready for public use, and after that use it as a foundation to add more features on top.

Tips for running with systemd would be greatly helpful. I use the VPN connection in an LXD container and it would be awesome not to have to manually re-run the script when I restart the container.

[g00nix]

v2.0.0 got released. I think we could create a separate folder with instructions for systemd.

[lukehmcc]

So I've been trying to get this to work for a while now and I though I'd drop a comment here.

So here's what I've done(I'm on F33 btw):

1. Clone the "manual-connections" repo to /usr/local/bin
2. Add this system file in /etc/systemd/system/piastart.service(with the sensitive details included ofc):

[Unit]
Description=Runs PIA over wiregaurd
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

[Service]
Environment='VPN_PROTOCOL=openvpn'
Environment='DISABLE_IPV6="n"'
Environment='AUTOCONNECT=true'
Environment='PIA_PF=false'
Environment='PIA_USER='
Environment='PIA_PASS='
Environment='PIA_DNS=true'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=never
Type=simple
User=root
[Install]
WantedBy=multi-user.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target

Yet I cannot seem to get it functioning with either openvpn or wiregaurd, I always seem to run into perms issues. Here are the respective error messages: Openvpn:

Apr 10 12:03:33 LAPTOPG14 bash[4616]: Trying to start the OpenVPN connection...
Apr 10 12:03:33 LAPTOPG14 openvpn[4628]: Warning: Error redirecting stdout/stderr to --log file: /opt/piavpn-manual/debug_info: Permission denied (errno=13)
Apr 10 12:03:33 LAPTOPG14 openvpn[4628]: Options error: --writepid fails with '/opt/piavpn-manual/pia_pid': Permission denied (errno=13)

Wiregaurd:

Apr 10 12:05:29 LAPTOPG14 bash[5742]: [#] nft -f /dev/fd/63
Apr 10 12:05:29 LAPTOPG14 bash[5787]: internal:0:0-0: Error: Could not open file "/dev/fd/63": Permission denied
Apr 10 12:05:29 LAPTOPG14 bash[5742]: [#] resolvconf -d pia -f
Apr 10 12:05:29 LAPTOPG14 bash[5742]: [#] ip -4 rule delete table 51820
Apr 10 12:05:29 LAPTOPG14 bash[5742]: [#] ip -4 rule delete table main suppress_prefixlength 0
Apr 10 12:05:29 LAPTOPG14 bash[5742]: [#] ip link delete dev pia
Apr 10 12:05:29 LAPTOPG14 systemd[1]: piastart.service: Succeeded.

I'm not exactly sure how I'm getting perms issues considering that systemd is running as root, and the wiregaurd is especially confuseing because it shouldn't even be attempting to read there because that isn't a file, but a pipe thingy...

If anyone has ideas that'd be great.

[Tatsujin]

I was able to get it to work (using WireGuard) thanks to your help:

root@meru:~# cat /etc/systemd/system/piavpn.service
[Unit]
Description=Runs PIA over wiregaurd
After=network-online.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='AUTOCONNECT=true'
Environment='PIA_USER=user'
Environment='PIA_PASS=pass'
Environment='PIA_DNS=true'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=simple
User=root

[Install]
WantedBy=network-online.target deluged.service

Note that I have it wait until deluged starts because I modified the port_forwarding.sh script to update deluge in step with the service polling PIA

    echo -e "\n${GREEN}This script will need to remain active to use port forwarding, and will refresh every 15 minutes.${NC}\n"

    /usr/bin/deluge-console -U user -P pass "config --set listen_ports ($port,$port)"

Now, the only remaining issue is that sometimes PIA seems to arbitrarily reject my login on boot, trying to figure that out.

[inspector71]

I was able to get it to work (using WireGuard) thanks to your help:

root@meru:~# cat /etc/systemd/system/piavpn.service
[Unit]
Description=Runs PIA over wiregaurd
After=network-online.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='AUTOCONNECT=true'
Environment='PIA_USER=user'
Environment='PIA_PASS=pass'
Environment='PIA_DNS=true'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=simple
User=root

[Install]
WantedBy=network-online.target deluged.service

Note that I have it wait until deluged starts because I modified the port_forwarding.sh script to update deluge in step with the service polling PIA

    echo -e "\n${GREEN}This script will need to remain active to use port forwarding, and will refresh every 15 minutes.${NC}\n"

    /usr/bin/deluge-console -U user -P pass "config --set listen_ports ($port,$port)"

Now, the only remaining issue is that sometimes PIA seems to arbitrarily reject my login on boot, trying to figure that out.

Did not experience permissions issues like @lukehmcc ?

[lukehmcc]

I was able to get it to work (using WireGuard) thanks to your help:

root@meru:~# cat /etc/systemd/system/piavpn.service
[Unit]
Description=Runs PIA over wiregaurd
After=network-online.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='AUTOCONNECT=true'
Environment='PIA_USER=user'
Environment='PIA_PASS=pass'
Environment='PIA_DNS=true'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=simple
User=root

[Install]
WantedBy=network-online.target deluged.service

Note that I have it wait until deluged starts because I modified the port_forwarding.sh script to update deluge in step with the service polling PIA

    echo -e "\n${GREEN}This script will need to remain active to use port forwarding, and will refresh every 15 minutes.${NC}\n"

    /usr/bin/deluge-console -U user -P pass "config --set listen_ports ($port,$port)"

Now, the only remaining issue is that sometimes PIA seems to arbitrarily reject my login on boot, trying to figure that out.

Did not experience permissions issues like @lukehmcc ?

There's a good chance that this could just be because I'm on a Red Hat based distro the security stuff is a bit tighter. Maybe they're on arch or something?

[jdkang]

I'm on Debian 11 (not RHEL) and came across similar timing issues.

A bit hacky but had to set the type to idle and add a sleep.

[Unit]
Description=PIA Wireguard
After=dns-check.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='AUTOCONNECT=true'
Environment='PIA_USER=<USER>'
Environment='PIA_PASS=<PASSWORD>'
Environment='PIA_DNS=false'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
TimeoutStartSec=infinity
ExecStartPre=/bin/sleep 5
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=idle
User=root

dns-service.service is something I had to write because fstab CIFS mounts were booting too quickly but I also used it here too. Might be redundant with idle.

[Unit]
  Description=check if DNS is up before proceeding
  After=network-online.target

[Service]
  Type=oneshot
  ExecStartPre=/bin/bash -c 'until host <DNS_NAME>; do sleep 1; done'
  ExecStart=/bin/bash -c 'echo "DNS up!"'

[Install]
  WantedBy=multi-user.target

[MrSJDDevelopments]

I was able to get it to work (using WireGuard) thanks to your help:

root@meru:~# cat /etc/systemd/system/piavpn.service
[Unit]
Description=Runs PIA over wiregaurd
After=network-online.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='AUTOCONNECT=true'
Environment='PIA_USER=user'
Environment='PIA_PASS=pass'
Environment='PIA_DNS=true'
Environment='PIA_PF=true'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=simple
User=root

[Install]
WantedBy=network-online.target deluged.service

Fantastic work on this script Have managed to et wireguard fireing up automaticly & have the system reconecting every 23 hours to maintain connectivity..... Im stuck trying to get Transmission to automaticly update the port number to PIA... any ideas hos i can do this ?.

[g00nix]

Do you guys think it's OK if we add that systemd example to the README and close the ticket?

[lukehmcc]

Do you guys think it's OK if we add that systemd example to the README and close the ticket?

Yeah that sounds good

[catfoobar]

Got to this party late - wondering if you all have any suggestions -

sudo VPN_PROTOCOL=wireguard DISABLE_IPV6=yes DIP_TOKEN=no AUTOCONNECT=true PIA_PF=false PIA_DNS=true PIA_USER=pxxxxxxx PIA_PASS=xxxxxx ./run_setup.sh

This works on the command line. Can connect.

When trying to duplicate above, simply, my piavpn.service is

[Unit]
Description=Runs PIA over wiregaurd
After=network-online.target

[Service]
Environment='VPN_PROTOCOL=wireguard'
Environment='DISABLE_IPV6=yes'
Environment='DIP_TOKEN=no'
Environment='AUTOCONNECT=true'
Environment='PIA_PF=false'
Environment='PIA_DNS=true'
Environment='PIA_USER=pxxxxxxx'
Environment='PIA_PASS=xxxxxxxxxx'
WorkingDirectory=/usr/local/bin/manual-connections
ExecStart=/bin/bash /usr/local/bin/manual-connections/run_setup.sh
Restart=no
Type=simple
User=root

[Install]
WantedBy=multi-user.target

Executed: sudo systemctl daemon-reload sudo systemctl enable piavpn.service

No worky.

   systemctl status piavpn.service
    ● piavpn.service - Runs PIA over wiregaurd
         Loaded: loaded (/etc/systemd/system/piavpn.service; enabled; vendor preset: enabled)
         Active: activating (start) since Thu 2023-11-30 18:48:35 PST; 36s ago
       Main PID: 829 (bash)
          Tasks: 1 (limit: 1595)
            CPU: 35.122s
         CGroup: /system.slice/piavpn.service
                 └─829 /bin/bash /usr/local/bin/manual-connections/run_setup.sh

    Nov 30 18:49:07 pi3 bash[829]: PIA password:
    Nov 30 18:49:07 pi3 bash[829]: You must provide input.
    Nov 30 18:49:07 pi3 bash[829]: PIA password:
    Nov 30 18:49:07 pi3 bash[829]: You must provide input.
    Nov 30 18:49:07 pi3 bash[829]: PIA password:
    Nov 30 18:49:07 pi3 bash[829]: You must provide input.
    Nov 30 18:49:07 pi3 bash[829]: PIA password:
    Nov 30 18:49:07 pi3 bash[829]: You must provide input.
    Nov 30 18:49:07 pi3 bash[829]: PIA password:
    Nov 30 18:49:07 pi3 bash[829]: You must provide input.

Any help? raspi 3B+ HW, Debian 11.8, OS bullseye, headless, Wireguard v1.0.20210223-1. Can't tell you how many systemd pages I visited trying to get some joy.

[catfoobar]

Never mind. Issue is how characters/strings are processed differently via command line versus systemd. Specifically, escape sequences. Will try to figure that out on my own : )

I never mentioned how I spent days trying to figure out how to connect to PIA with CLI using terrible web search "how-to's" always resulting in failures. The TLDR solution in this post was the only thing that actually worked.

Thanks!