tplink_smb wrote

Dear all members, glad to tell you that the Linux version controller has been developed and is during the uploading process, it will be online within several days.

Great! Thanks for the notification!

Great!

But there is a bug in the control.sh start/stop script: it creates a logfile "stop.log" in the bin subdirectory instead of in the logs directory if the Controller is stopped. Probably unnoticed by QC because of the same reason why a similar bug in Pharos Control ( /dev/nyll instead of /dev/null in its start/stop script) did pass through: missing privilege separation.

Please, TP-Link, why can't we run this software as an unprivileged user as it is common standard in Linux? It's of course o.k. to ask for root permissions to install software, but it's definitely not so to have to run the application as the root user, especially not for a web-based service!

If I start the EAP Controller as an unprivileged user, I get the error message:

A non-root user can't receive a broadcast packet if the socket is not bound to a wildcard address; binding to a non-wildcard address (/192.168.1.25:0) anyway as requested.

Uhm, what's the point to bind to the primary IP address of the server instead of to the wildcard address, which would be possible for non-root users, too?

Is this the only place where root permissions are needed for in the EAP Controller? If so, please can you change this to bind to the wildcard address?

Anyway, I have adapted the start/stop script to my Debian Linux version. This fixes the bug mentioned above and also prepares for rudimentary privilege separation by switching to a role account ( "eapc" in the script, could be any other user ID you prefer) before starting the EAP Controller.

Until it's clear wether binding the socket is the only place which needs root permissions because of not using a wildcard address, I have uncommented the unprivileged user so that the start/stop script runs the EAP Controller as root and therefore it is fully compatible to the original script.

It also adds a restart function, fully complies to the Linux Standard Base (LSB) and removes unnecessary clutter from the original script.

Just name it control.sh and put it into the eapHome/bin subdirectory:

[CODE]
#!/bin/bash
### BEGIN INIT INFO
# Provides: eap
# Required-Start: $local_fs $remote_fs $network $syslog
# Required-Stop: $local_fs $remote_fs $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: EAP Controller
# Description: Start the EAP Controller and the MongoDB server
# This script will start eap and the mongod database server.
### END INIT INFO

DESC="EAP Controller"

# Role account for privilege separation.
#
# Set to "root" if you really want to run a web-based service
# with full administrative permissions (not recommended!).
EAPC_USER=root
#EAPC_USER=eapc

EAPC_HOME="$(readlink -f $0)"
EAPC_HOME="${EAPC_HOME%/*/*}"
EAPC_LOG="$EAPC_HOME/logs"

JRE_HOME=$EAPC_HOME"/jre"
JAVA_TOOL=$EAPC_HOME/jre/bin/java
JAVA_OPTS="-Xms128m -Xmx1024m -XX:MaxHeapFreeRatio=60 -XX:MinHeapFreeRatio=30 -XX:+UseSerialGC -XX:+HeapDumpOnOutOfMemoryError"
JAVA_PATH="-cp $EAPC_HOME/lib/com.tp-link.eap.start-0.0.1-SNAPSHOT.jar:$EAPC_HOME/lib/*:$EAPC_HOME/external-lib/*"

# Check wether EAP Controller is running.
# Returns EXIT_SUCCESS if running, EXIT_FAILURE otherwise.
IS_RUNNING="$EAPC_HOME/bin/portt 127.0.0.1 8088 500"

# Check wether we are initially running as root so we can change privileges.
check_perms() {
[ $(id -ru) != 0 ] && { echo "You must be root to $1 the EAP Controller" 1>&2; exit 1; }
}

case "$1" in
start)
$IS_RUNNING && { echo "EAP Controller is already running." 1>&2; exit 1; }

check_perms $1

[ -e "$EAPC_LOG" ] || {
mkdir -m 755 $EAPC_LOG 2>/dev/null && chown $EAPC_USER $EAPC_LOG
}

echo -n "Starting EAP Controller " 1>&2
su $EAPC_USER -c "nohup $JAVA_TOOL -server $JAVA_OPTS $JAVA_PATH \
-Deap.home=\"$EAPC_HOME\" com.tp_link.eap.start.EapMain start >$EAPC_LOG/startup.log 2>&1 &"

let count=0
until $IS_RUNNING
do
echo -n "."
[[ count++ -gt 120 ]] && {
echo -e "\nStart failed - see '$EAPC_LOG/startup.log' for errors." 1>&2
exit 1
}
sleep 1
done
echo -e "\nEAP Controller started successfully."
echo "Direct your browser to http://127.0.0.1:8088 for access."
exit 0
;;

stop)
$IS_RUNNING || { echo "EAP Controller already stopped." 1>&2; exit 1; }

check_perms $1

echo -n "Stopping EAP Controller "
su $EAPC_USER -c "$JAVA_TOOL $JAVA_PATH \
-Deap.home=\"$EAPC_HOME\" com.tp_link.eap.start.EapMain stop >$EAPC_LOG/stop.log 2>&1 &"

let count=0
while $IS_RUNNING
do
echo -n "."; sleep 1
[[ count++ -gt 30 ]] && {
echo -e "\nCould not stop EAP Controller after 30 seconds - please try again." 1>&2
exit 1
}
done

echo -e "\nEAP Controller stopped successfully." 1>&2
exit 0
;;

restart)
check_perms $1

echo -n "Restarting EAP Controller " 1>&2
$0 stop && sleep 2 && $0 start
;;

status)
if $IS_RUNNING; then
echo "EAP Controller is running."
exit 0;
else
echo "EAP Controller is not running."
exit 1;
fi
;;

*)
echo "Usage: $0 (start|stop|restart|status)"
exit 1
;;
esac
[/CODE]

BTW: testing the shell variable UID for detecting the root user is a bug in the original script, too. Shell variables can be changed. Instead the command id -ru should be used to check for the root user as shown in the script above.

Ignore the warnings about initialization failure of log4j, it will be loaded again later on. See file server.log, it should read like this:

[CODE]
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : eap.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : mongodb.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : jetty.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : device.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : log4j.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : netty.properties
2017-08-13 17:25:03 [main] [INFO]-[ConfigurationFactory.java:39] - success to load configuration : user.params.properties
2017-08-13 17:25:08 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring root WebApplicationContext
2017-08-13 17:25:36 [main] [INFO]-[MonitorInit.java:39] - monitor context initialing...
2017-08-13 17:25:36 [main] [INFO]-[ContextHandler.java:2040] - Initializing Spring FrameworkServlet 'springMVC'
2017-08-13 17:25:38 [main] [INFO]-[DbCompatibleServcie.java:96] - no need to compatible db.
[/CODE]

If it does not, post all logfiles here, not just startup.log. The server.log is much more meaningful than startup.log.

PeterL. wrote

There's no sign of an error anywhere, besides the application is not starting up.

The app starts up indeed. But: this *()#$%^&- systemd kills the job as soon as su terminates.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 for details.

That's is the important message from the log, which you didn't include in your first post:

[CODE]
/usr/bin/tpeap: line 79: 2580 Killed nohup $JAVA_TOOL ...
[/CODE]

This is just another catastrophic bug of systemd, which replaced the 40 years old, stable and robust initializer init, just because some people think it would be a good idea to replace the system's initializer by a monolithic monster program handling everything in order to make things better than init does, even at the risk of breaking lots of other software packages.

Find attached a version of tpeap which does not use nohup and su. This should work with your version of systemd. If I have some spare time, I probably will integrate the start/stop script in systemd, but changes are that I will drop systemd completely, since it causes lot of other troubles on our servers, too.

PeterL. wrote

Believe it or not, but it's still not working.

I have no reason to not believe you. :)

Did the "kill" message disappear now? And did you test the original script control.sh, too?

Not sure wether you can go back to SysV init on Debian 9. According to Debian's last announcements they planned Debian 8 to be the last version which allows SysV init. There is already a fork of Debian called Devuan, which will support the SysV init in future versions, too - there is more work to do than just to replace systemd by init, thanks to the non-modular, Windows-like concept of having systemd take over every OS functionality it can.

It would not make me wonder if systemd will soon be able to brew coffee, too, but then will require to patch your coffee machine in order to heat up the water. :D