Jonas_TP-Link wrote

EAP Controller supporting 64-bit Linux operating system, including Ubuntu 14.04/16.04/17.04, CentOS 6.x/7.x and Fedora 20 or above.
and require JRE 1.7 (or above) Java environment.

I don't want to hijack this tread, but there are serious problems with the install.sh and bin/control.sh scripts, which prevent installation and which also can prevent the start of the EAP Controller on Debian Linux, which is the core system for Ubuntu and many other Linux distributions. Albeit both scripts have the same bug, the installation could proceed in certain situations, but the start/stop script might fail.

The problems arise with the check for root permission. This check is done using:

[CODE]if [ $UID != ${ROOT_UID} ]
then ...[/CODE]

in both scripts. There are as much as three (!) bugs in this tiny line, leading to a fourth - even more serious - bug. Here we go:


Bug #1: missing apostrophes around shell variables which can be empty. If executed in its original form, the shell script prints an error for the check:

[CODE]# sh ./install.sh
./install.sh: 114: [: !=: unexpected operator
EAP Controller will be installed in [/opt/tplink/EAPController] (y/n):[/CODE]

but it will continue to run. This way, you can indeed install the EAP Controller if you are root already.


Bug #2: Albeit UID is set by the login shell, it is not (always) exported from the login shell to subshells. If the script is executed by a subshell like in " sh ./install.sh", it will barf even if you are root since UID is now empty. You will notice this error if you try to fix bug #1. Let's use apostrophes around the variable names to reveal this bug:

[CODE]if [ "$UID" != "${ROOT_UID}" ]
then ...[/CODE]

Now even if run by root, the script exits with an error message (and this bug could have been noticed during test phase if there had not been Bug #1 already):

[CODE]# sh ./install.sh
The script need root permission. Exit.
# [/CODE]

You can only "fix" this by manually exporting UID in your login shell as in " export UID; sh ./install.sh".


But then comes Bug #3, the most important bug: Never ever use the shell variable UID to check for root permissions. Otherwise everybody can run:

[CODE]UID=0 ./install.sh[/CODE]

to spoof his/her real user ID as being root for your script. This leads us to Bug #4: Everybody on the server (even non-root users) can stop an already running EAP Controller by using " UID=0 bin/control.sh stop", albeit it can not be started this way.

Fix: Use the command " id -u" to get the real user ID, which can't be spoofed. This is how to test for root permission on Linux (note also the correct numeric test operator ' -ne' instead of the string comparison operator ' ='):

[CODE][ $(id -u) -ne 0 ] && { echo "You must be root to run this script. Exit." 1>&2; exit 1; }[/CODE]


BTW: I did inform several people at TP-Link including support about this bug for all Linux versions of EAP Controller released so far and also for Pharos Control, which uses the same buggy construct.

I really recommend my start/stop script as a replacement for the bin/control.sh script as it fixes those bugs since EAP Controller 2.4.8 already:
http://forum.tp-link.com/showthread.php?97236-EAP-Software-Why-not-available-for-Linux-as-Docker-image&p=210127&viewfull=1#post210127

It even avoids other incompatible constructs supported by only some shells like bash, but not by sh:

[CODE]if [[ $confirm = "Y" || $confirm = "YES" ]]; then[/CODE]

leads to:

[CODE]# sh ./install.sh
EAP Controller will be installed in [/opt/tplink/EAPController] (y/n): y
./install.sh: 23: ./install.sh: [[: not found
./install.sh: 23: ./install.sh: Y: not found
./install.sh: 25: ./install.sh: [[: not found
./install.sh: 25: ./install.sh: Y: not found
EAP Controller will be installed in [/opt/tplink/EAPController] (y/n):
#[/CODE]

And so on ...