Leaderboard

me too, but only on my laptop. My PC works just fine with version 2.19.7. Both have Windows 10 Pro 20H2 fully updated. Both have TAP-Windows 9.24.2 installed. Both use ESET Internet Security. In Computer Settings-> Services and Applications-> Services-> Eddie Elevation Service, I'm unable to start it on my laptop. One difference: my PC runs on AMD Ryzen 7 3700X 8-Core and my laptop runs on Intel Core-i7-6700HQ CPU. PROBLEM SOLVED!! ... The Eddie Elevation Service was present even when Eddie had been de-installed, and it was not possible to start this service manually. Installing OpenVPN did not help so I de-installed it too. By this time TAP-Windows 9.24.2 had disappeared. I then deleted the following key manually in the Registry Editor: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EddieElevationService. (There are cleaner ways to remove Services.) After that, installing Eddie 2.19.7 worked perfectly. Note that before this I had been using Eddie 2.18.9 (and earlier versions) for ages without a problem.

My target system: Headless Raspberry Pi 2 Model B Rev 1.1 system via ssh. $ uname -a> Linux xbian 4.19.90+ #1 SMP PREEMPT Wed Dec 18 20:39:10 CET 2019 armv7l GNU/Linux ## based on Debian GNU/Linux 10 (buster) My use case is to have this box come up on boot fully protected - VPN / DNS / firewall and stay that way. My first effort was to eddie-cli in rc.local and I hit a few roadblocks but figured out the following: 1. The script /etc/rc.local runs as root, but eddie-cli expects to be run by an unprivileged user (it is installed in /usr/bin). 2. Also, /etc/rc.local does not, by default provision a terminal (ttx) while eddie-cli depends on it. These two issues can be addressed using the su command "su -P -c 'eddie-cli ....{options)...' User." The command su -c lets rc.local run it as a normal user and the -P option gives rc.local access to a pseudo-terminal. 3. Even when the -batch directive is used, some forking program wants a typed password when escalating privileges during startup. In order to get around that I gave my user password-free access via sudo by editing the sudoers file as set out here: https://linuxhandbook.com/sudo-without-password/ The command eddie-cli executes via sudo, is /usr/lib/eddie-cli/eddie-cli-elevated, and there also exists /usr/lib/eddie-cli/eddie-cli-elevated2 Using the # visudo command to allow nopassword sudo for just these these two commands: xbian ALL=(ALL) NOPASSWD:/usr/lib/eddie-cli/eddie-cli-elevated,/usr/lib/eddie-cli/eddie-cli-elevated2 This 3-part kludge actually works well. But better yet would be to have eddie-cli run as a proper init service. For standard Debian 10 systems that would require writing a SystemD unit file, etc. Or, since SystemD runs rc.local as a service, you could try just using the command that follows "exec" below at the end of the /etc/rc.local file. Good scripting practice would also include tests so that rc.local exits with zero on success and non-zero on failure. I think you would then be able to control eddie-cli by using systemctl against the rc.local service, but I haven't checked this out. Xbian, to their credit, eschews SystemD and uses instead Canonical's older Upstart init system -- an improvement over SystemV without the borg-like expansiveness of SystemD. After digging a bit, I have put together a configuration file based on the one that existed for OpenVPN and it works exactly as advertised. The system boots protected and I can manage eddie-cli with Upstart's start, stop, and status commands while the output is logged to /var/log/upstart/eddie-cli.log. $ cat /etc/init/eddie-cli.conf start on (net-device-up and local-filesystems and runlevel [2345]) stop on runlevel [!2345] env PIDFILE="/var/run/eddie-cli/eddie.pid" respawn respawn limit 6 60 pre-start script if [ ! -e /var/run/eddie-cli ]; then mkdir -m 0770 /var/run/eddie-cli chown nobody:nogroup /var/run/eddie-cli fi end script exec su -P -c "/usr/bin/eddie-cli \ -netlock \ -login=airvpnclient \ -password=***************** \ -server=Rotanev \ -connect \ -batch" \ xbian pre-stop script PID=`cat $PIDFILE` kill -15 $PID sleep 3 if [ "$?" -eq 0 ]; then rm -f $PIDFILE else echo "Unable to stop VPN" fi end script post-stop exec sleep 5 ### I will also want to add to the post-stop command an iptables-restore command, against some tables I saved on the desktop ### so swap for something like: # post-stop exec "sleep 5 && /usr/sbin/iptables-legacy restore < /etc/eddie-cli/airvpn.tables && /usr/sbin/ip6tables-legacy restore < /etc/eddie-cli/airvpn.6tables" ### since if the service hits its respawn limit for some reason and stops, there would be no firewall ### and other services would be exposed. Hope this helps someone.

Edit: Because this post continues to bring people to my github page, I'd like to make things a bit easier. I have pushed my images to Dockerhub, so you no longer need to build these images yourself. Unfortunately there are still a few manual steps. Here's a step-by-step to get this running: 1) You still need to install Docker and docker-compose as described below. 2) You need to grab two files from my repository. https://github.com/rahmnathan/docker/blob/master/deluge/docker-compose.yml and https://github.com/rahmnathan/docker/blob/master/deluge/airvpn/resolv.conf 3) In the docker-compose file that you grabbed, you need to set the USERNAME and PASSWORD environment variables to your AirVPN credentials. 4) In the docker-compose file that you grabbed, you need to update the 'volumes' section to point to the resolv.conf file that you grabbed. This file configures Air to use AirVpn's DNS servers. Normally this is automatic with eddie, but there are some issues in Docker that currently prevent this, so it needs to be mapped as a volume. 5) Run 'docker-compose up -d' in the directory of the docker-compose.yml file. More often than not, the airvpn container stops at 'Ready' before AirVPN connects. I haven't resolved this yet, but if you toggle 'docker-compose down'/'docker-compose up -d' a few times, it eventually goes through. If anyone knows why this is happening, please let me know or submit a pull request against my repo and I'd be happy to merge it. To expand on that, if anyone has any suggestions, I'd be happy to implement them or accept PRs. --------------------- After several days of grind, I was finally able to get my vpn/deluge Docker swarm working properly. The goal of this was to create an isolated/portable environment to use my vpn so I could run it without changing the external IP of everything else running on the host system. Fair warning, I'm terrible at how-to's... The first thing you'll want to do is install Docker and Docker Compose. I like DigitalOcean's guides for this.. Docker -> https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-16-04 Docker Compose -> https://www.digitalocean.com/community/tutorials/how-to-install-docker-compose-on-ubuntu-16-04 Now you can follow the instructions located here -> https://github.com/rahmnathan/docker . Brief Explanation: vpn - This image downloads, configures, and runs Air's Eddie client. deluge - This image downloads, configures, and runs the Deluge deamon. This image will use the network of the 'vpn' container, which is completely locked down outside of the docker swarm unless it's through the vpn. That brings us to... nginx - This image downloads, configures, and runs nginx. Because our swarm's network is isolated from the host's we need to utilize nginx as a reverse proxy to get into it. This is simply a gateway for us to access the Deluge daemon. Hopefully that's enough information for anyone interested to get started. The cool thing about this is you can force any container through the vpn while leaving the host machine/other containers running outside of the vpn. This gives us a very scalable, portable, isolated way to use the awesome service provided by Air. Feel free to ask questions and suggest edits. Thanks