21 replies to this topic

[Balop]

Hello,

 

i've installed OpenPLI 8 on my Octagon SF8008 and i've also installed OpenVPN that is working fine if i start and stop it manually.

My problem is that i used this command for startup it: update-rc.d openvpn defaults

with the output "Adding system startup for /etc/init.d/openvpn."

 

but isn't working, in fact everytime i reboot, OpenVPN doesn't startup and i've to do it manually.

 

I've checked the symbolic link into the folders rcX.d and i've seen them into rc2.d, rc3.d, rc4.d e rc5.d but after reboot them disappear.

 

Can you help me?

 

Thank you

 

[s3n0]

Hi.

 

Shell script "/etc/init.d/openvpn" exists ? Does the script have execution rights assigned to it ("chmod a+x /etc/init.d/openvpn") ?

 

If you install OpenVPN, you don't have to change anything. Autostart should be automatically initialized if I'm not mistaken. Just adjust the OpenVPN configuration as you need and restart the set top box.

 

BTW, instead of OpenVPN I use a much simpler ZeroTier (free VPN project, ready for different platforms).

[Balop]

Hi, 

 

the script "/etc/init.d/openvpn" exists and has the rights 755 assigned, in fact if i start/stop it manually it works correctly, the problem is only the startup.

Startup config isn't done during the installation, in fact with my old decoder i had to run the command "update-rc.d openvpn defaults" as read on internet

but with this new decoder this command doesn't works correctly.

 

I'll search about this ZeroTier 

 

Thank you

[s3n0]

Hi.

 

Can you show what the "/etc/init.d/openvpn" shell script contains ? Paste into CODE TAG of course. Is it a standard OpenVPN installation package from the OpenPLi feed ? There will probably be some error in this "init.d" script. It works after installing OpenVPN, but it doesn't work when restarting the set-top box ... right ?! This could mean that after installation, the OpenVPN is started in a different way (by the installer) than through the "init.d" script. I don't really know ... I'm just guessing the possible cause of your problem.

 

It is also possible that you have an incorrect or unlocalized OpenVPN configuration ("server.conf" file) in one of the directories. Then the OpenVPN may not start correctly.

[WanWizard]

The standard OpenVPN package from the feed creates all the necessary files, and does start automatically on boot. Providing there is a working config of course.

[s3n0]

Hi.

 

Sure ... but let the interviewer comment on what I wrote. He claims in the first place that when rebooting the set-top box, all symbolic links from the "rcX.d" folders for the openvpn script will be deleted.

 

We need to find out why this is happening. Of course, it is also possible to manually insert a symbolic link at least into the "rc3.d" folder (run level 3). For example:

# For add (install) the startup sym-links to run-level No.3 (Enigma2 default run-level):
ln -sf /etc/init.d/openvpn /etc/rc3.d/S30openvpn

# For remove (uninstall) the symbolic link you can simply delete this link:
rm -f /etc/rc3.d/S30openvpn

Remember to remove all previous openvpn links created by the "update-rc.d" tool beforehand:

update-rc.d -f openvpn remove

rm -f /etc/rc?.d/{S,K}??openvpn

If this way of manually adding a symbolic link to the "rc3.d" folder will work (unfortunately only for run-level-3, what is not enough, but it will work), then we still will not find out where the cause of this problem is.

 

I don't know why the symbolic-links from the "rcX.d" folders were deleted after reboot. In addition to "update-rc.d SCRIPNAME defaults" we need to use the "update-rc.d SCRIPTNAME enable" command when install the OpenVPN package. I really have no idea where the problem with this OpenVPN is in OpenPLi 8.0 (I currently only have the 8.0-RC version installed).

Edited by s3n0, 10 March 2021 - 16:36.

[WanWizard]

The only thing I can think of is that OpenVPN has a dependency on the network interface. If the SF8008 is used with wireless instead of wired, it could be the interface isn't up yet when OpenVPN starts.

[s3n0]

Um, maybe you're right ... that could be the cause.

 

In that case, "S30..." should be changed (shifted) at least to a later start order, for example to "S90..." . That is, if it does not interfere with the system. I don't use OpenVPN so I don't know if it will interfere.

[WanWizard]

Not sure that will help a lot, especially on faster boxes.

 

For NTP, we've switched to triggering by an ifup script. We might have to do the same for OpenVPN, and run "/etc/init.d/openvpn start" after the interface comes up...

[Balop]

Hi, i'm reading only now your messages. Then, this is the code into /etc/init.d/Openvpn

start_vpn () {
    modprobe tun >/dev/null 2>&1 || true
    # make sure the device node exists
    if [ ! -c /dev/net/tun ]; then
        if [ ! -d /dev/net ]; then
            mkdir /dev/net
        fi
        mknod /dev/net/tun c 10 200
        chmod 600 /dev/net/tun
    fi
    start-stop-daemon --start --quiet --pidfile /var/run/openvpn.$NAME.pid \
            --exec $DAEMON -- \
            --data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:BF-CBC \
            --daemon --writepid /var/run/openvpn.$NAME.pid \
            --config $CONFIG_DIR/$NAME.conf --cd $CONFIG_DIR || rc="$?"
    case $rc in
        1) echo -n " ALREADY STARTED->";;
        3) echo -n " FAILED->";;
    esac
    echo -n " $NAME"
}

I tried to manually create the symbolic link but it's always the same thing.

 

At the end i solved in this way:

i've created an sh that start vpn (/etc/init.d/openvpn start)

i've copyed it into /etc/init.d/

i gave it the rights 755

i've executed the command "update-rc.d script.sh defaults"

 

Now startup is working fine!

[WanWizard]

I hope there's more code than only that, otherwise there is a big chunk missing...

[s3n0]

So the problem was that you ignored the ".sh" file extension that you forgot to add to the file name ? Or how do I understand it ?

 

Or there this ".sh" file extension should not be there ... and you just renamed / copied / pasted a new script file ? Did you rename it to a new name - with the extension ".sh" ? Subsequently, this "openvpn.sh" file remained there and was not deleted after rebooting ?

 

This can also be a small problem, as the "/etc/init.d/openvpn" script may be referenced by several algorithms. There may be a small problem there in certain situations. Maybe it will work properly.

 

Rather, you should have found out why the "/etc/init.d/openvpn" script is being deleted. For example, by activating and monitoring the enigma2 debug log. Or by watching "/var/log/messages" logs, but I don't know if deleting the "openvpn" script is stored there . Probably not, but at least there could be an error message, for example: cat /var/log/messages | grep -i 'vpn' . This could be, for example, a problem with the installation package manager (opkg) or a problem with the installation scripts themselves in the OpenVPN package.

 

BTW, I wanted to see the whole script, not just the "start" part of the script - by argument.

 

Will only "rc?.d" symbolic links be deleted after restarting ? Or will the script in "init.d" also be deleted ?

Edited by s3n0, 13 March 2021 - 09:31.

[Pike_Bishop]

the complete init script here in pli-8 looks as following;

#!/bin/sh -e
#
# Original version by Robert Leslie
# <rob@mars.org>, edited by iwj and cs
# Modified for openvpn by Alberto Gonzalez Iniesta <agi@agi.as>
# Modified for restarting / starting / stopping single tunnels by Richard Mueller <mueller@teamix.net>
# Modified for respecting pid file on service start by Fabian Klemp <fabian.klemp@axino-group.com>

test $DEBIAN_SCRIPT_DEBUG && set -v -x

DAEMON=/usr/sbin/openvpn
CONFIG_DIR=/etc/openvpn
test -x $DAEMON || exit 0
test -d $CONFIG_DIR || exit 0

start_vpn () {
    modprobe tun >/dev/null 2>&1 || true
    # make sure the device node exists
    if [ ! -c /dev/net/tun ]; then
        if [ ! -d /dev/net ]; then
            mkdir /dev/net
        fi
        mknod /dev/net/tun c 10 200
        chmod 600 /dev/net/tun
    fi
    start-stop-daemon --start --quiet --pidfile /var/run/openvpn.$NAME.pid \
            --exec $DAEMON -- \
            --daemon --writepid /var/run/openvpn.$NAME.pid \
            --config $CONFIG_DIR/$NAME.conf --cd $CONFIG_DIR || rc="$?"
    case $rc in
        1) echo -n " ALREADY STARTED->";;
        3) echo -n " FAILED->";;
    esac
    echo -n " $NAME"
}

stop_vpn () {
   kill `cat $PIDFILE` || true
  rm $PIDFILE
}

case "$1" in
start)
  echo -n "Starting openvpn:"

  if test -z $2 ; then
    for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
      NAME=${CONFIG%%.conf}
      start_vpn
    done
  else
    if test -e $CONFIG_DIR/$2.conf ; then
      NAME=$2
      start_vpn
    else
      echo -n " No such VPN: $2"
    fi
  fi
  echo "."

  ;;
stop)
  echo -n "Stopping openvpn:"

  if test -z $2 ; then
    for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
      NAME=`echo $PIDFILE | cut -c18-`
      NAME=${NAME%%.pid}
      stop_vpn
      echo -n " $NAME"
    done
  else
    if test -e /var/run/openvpn.$2.pid ; then
      PIDFILE=`ls /var/run/openvpn.$2.pid 2> /dev/null`
      NAME=`echo $PIDFILE | cut -c18-`
      NAME=${NAME%%.pid}
      stop_vpn
      echo -n " $NAME"
    else
      echo -n " No such VPN: $2"
    fi
  fi
  echo "."
  ;;
# We only 'reload' for running VPNs. New ones will only start with 'start' or 'restart'.
reload|force-reload)
  echo -n "Reloading openvpn:"
  for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
    NAME=`echo $PIDFILE | cut -c18-`
    NAME=${NAME%%.pid}
# If openvpn if running under a different user than root we'll need to restart
    if egrep '^( |\t)*user' $CONFIG_DIR/$NAME.conf > /dev/null 2>&1 ; then
      stop_vpn
      sleep 1
      start_vpn
      echo -n "(restarted)"
    else
      kill -HUP `cat $PIDFILE` || true
#    start-stop-daemon --stop --signal HUP --quiet --oknodo \
#      --exec $DAEMON --pidfile $PIDFILE
    echo -n " $NAME"
    fi
  done
  echo "."
  ;;

restart)
  $0 stop $2
  sleep 1
  $0 start $2
  ;;
*)
  echo "Usage: $0 {start|stop|reload|restart|force-reload}" >&2
  exit 1
  ;;
esac

exit 0

# vim:set ai et sts=2 sw=2 tw=0:

but i think @Balop has postet only a snippet (the start part) from the script openvpn

 

 

regards

Pike

Edited by Pike_Bishop, 13 March 2021 - 22:40.

[WanWizard]

Looks fine. The ipk's postinst will run update-rc.d after installation:

#!/bin/sh
set -e
if true && type update-rc.d >/dev/null 2>/dev/null; then
	if [ -n "$D" ]; then
		OPT="-r $D"
	else
		OPT="-s"
	fi
	update-rc.d $OPT openvpn start 10 2 3 4 5 . stop 70 0 1 6 .
fi

So the /etc/rc3.d symlink should be there.

 

There is nothing in the image that would remove sysinit links, so I can't come up with any reason, other than some plugin (that wants to generate a config before starting it for example).

[s3n0]

I wanted to test it, but unfortunately the new OpenPLi 8.0 released version (2021-03-08 build) does not work via OpenMultiboot, on my Vu+ Solo SE V2 (the main firmware in the flash drive is OpenATV 6.4). I don't know why he doesn't want to boot it. The strange thing is that the OpenPLi 8.0-RC version worked OK via OpenMultiboot. I wanted to test it, but unfortunately now OpenMultiboot does not work with PLi-8.0.

 

This problem with the loss of symbolic-links in Octagon devices could be caused by the late-loading filesystem of the internal flash drive. Then, if the file "/etc/init.d/openvpn{.sh,}" is not found, of course the symbolic links will be lost / deleted. In the case of the Octagon, flash drives are handled in a slightly strange way . As far as I know, flash drives are divided into several parts, for the possibility of booting multiple systems in Octagon devices. Or am I wrong ? Maybe there was a mistake in that regard.

 

Or maybe there's a wrong script name regarding the ".sh" file extension. Maybe the name of the shell-script file has been changed, by some plugin or by the user .

[Balop]

Hi s3n0,

in /etc/init.d the file OpenVPN hasn't extension so the first command i've posted is correct, in fact i used that command without problem with my older Sunray SR4 with OpenPLI 6.1 and works fine.

 

Thanks Pike_Bishop for the complete script, i posted only the start part.

[s3n0]

Yes, but you wrote that you then renamed the file name (you added the ".sh" extension to the file name). And that solved the problem.

[WanWizard]

Linux doesn't use nor care about "extensions". A file is executable because the X bit is on, not because of some extension. Extensions are just part of the filename.

 

If /etc/init.d/openvpn isn't executable, it has been tampered with, because the one in the feed is.

root@vuduo4k:~# opkg install openvpn
Installing kernel-module-tun-4.1.45-1.17 (4.1.45) on root
Installing openvpn (2.5.0) on root
Configuring kernel-module-tun-4.1.45-1.17.
Configuring openvpn.
 Adding system startup for /etc/init.d/openvpn.
root@vuduo4k:~# ls -l /etc/init.d/openvpn 
-rwxr-xr-x    1 root     root          3008 Jan 10 23:10 /etc/init.d/openvpn
root@vuduo4k:~# 

[s3n0]

@WanWizard:

 

I don't know who you're writing this to, but I guess not. I mastered these things about the basics of Linux systems 20 years ago.

 

I asked my question @Balopa ... because he wrote, just that he used the ".sh" extension to the file name and since then it has been working. This means that after rebooting something in its Enigma will always delete the script "/etc/init.d/openvpn", while the script "/etc/init.s/openvpn.sh" will remain on disk.

 

 

....

 

My problem is that i used this command for startup it: update-rc.d openvpn defaults

with the output "Adding system startup for /etc/init.d/openvpn."

 

but isn't working, in fact everytime i reboot, OpenVPN doesn't startup and i've to do it manually.

 

....

 

....

 

the script "/etc/init.d/openvpn" exists and has the rights 755 assigned, in fact if i start/stop it manually it works correctly, the problem is only the startup.

 

....

 

....

 

At the end i solved in this way:

i've created an sh that start vpn (/etc/init.d/openvpn start)

i've copyed it into /etc/init.d/

i gave it the rights 755

i've executed the command "update-rc.d script.sh defaults"

 

Now startup is working fine!

 

[WanWizard]

Sorry, was addressed to @Balop.

 

No idea what (s)he's doing and what the problem is, never experienced any of these issues.