g2_ufo wrote

Feature request:

 

1) It would be perfect if user can restoring previously omada controller config on first new controller startup.

You can save the content of the data directory somewhere before changing the config or use the backup feature built into Omada Controller to save it. This way it can be restored easily.

2) ARM adobted deb package for raspberry pi distro 

 

RasPi has not enough resources to run Omada Controller, but if you really want to do so, just add links to Raspbian's mongod and jsvc in the bin subdirectory (i.e. remove the binaries bundled with Omada Controller and replace it by standard software already included in Raspbian). The Java part of Omada Controller is architecture-independent and it runs fine on ARM architectures.

g2_ufo wrote

1) yes, i can copy data directory but it is not user frandly.... Unifi controller has it

Then why not use backup/restore? It's already there in Omada Controller.

2) RasPi has enough resources to run Omada Controller for 5-10 wifi point and it is enough for more people (OC200 controler is not much more powerful). Unifi also supports this ARM platform...

 

I once did create the .deb packages for Omada Controller 2.5.0 to 3.0.1 (community version) for use on Raspbian, but I dropped further builds of newer controller versions b/c RasPi couldn't keep up with its resources even with a handful of APs.

Note that I'm not from TP-Link. Maybe they might be willing to support the ARM architecture/RasPi with a down-stripped controller software in the future, but that would get them in competition with OC200, which is ARM-based, too, but has more resources just for running the controller than a RasPi running standard Raspbian/Debian.

g2_ufo wrote

My controller works perfect with 3 access point on Raspi.

Hello @g2_ufo,

ok, here is it: an all-architectures .deb-package of Omada Controller 3.1.13 suitable for RasPi and any other CPU architecture. I did a quick build, no fine-tuning.

Prerequisites:

You will need the native versions of JRE, jsvc and mongod (installed by default in Raspbian based on Stretch). The .deb-package does not contain any binaries, just the Java classes from the official TP-Link distribution and my shell script to manage the controller. The versions of the required binaries on my RasPi are:

Java(TM) SE Runtime Environment (build 1.8.0_65-b17)

jsvc 1.0.15-7

mongodb version v2.4.14

Notes:

• Installation directory is /opt/tplink/OmadaController-3.1.13. /opt/tplink/OmadaController is a short-hand alias/symlink to the former directory.
• Start/stop script has been renamed to omadactl (tpeap is still there, it's a symlink to omadactl).
• If installing using dpkg, you won't be able to switch between versions of the controller using omadactl's switch command.
• dpkg will remove older versions of the same package omada-controller, but it won't delete the old database unless you do a manual purge before installing.
• Some options of omadactl make no sense with only one version of the controller installed. However, restoring old files from previous controller versions with omadactl should work, even after an installation of the new version.

Donwload

Connect via ftp (not a web browser) to ftp.rent-a-guru.de, use passive mode. Log in using anon ftp (username: anonymous, Password: your mail address). Once connected, change directory to /private. You won't see any fies therein, it's a private directory. Just issue the command get omada-controller_3.1.13-1_all.deb to receive the file.

Checksum/md5sum is: 084acb9dd106d79b16fbe6d3b9e49b5d *omada-controller_3.1.13-1_all.deb

Installation

Install with: dpkg -i omada-controller_3.1.13-1_all.deb

After installation, the controller will be started automatically. On my RasPi 3 model B it needs 58 seconds to start.

For help with omadactl see the manpage.

Enjoy!

This works, too. But see omadactl, it has many more useful options than the control.sh and it even has a manpage like every Unix/Linux command should have.

Also, JRE_HOME needs not to be set. The netstat cmd can be easily integrated in control.sh (is already in omadactl), no need for a second script. The grep can be omitted in the port test, netstat already has an exit status telling about match/no match. Java runs fine in server mode on RasPi 3, only older models need -client option. omadactl also manages copying databases forth and back, no need for manual copies.

And most important: the omada-controller package corrects lazy file permissions in the official version so that unprivileged users can't read sensitive data from the keystore and the properties. This is an important part of privilege separation, too.

g2_ufo wrote

 

TP-LINK TEAM, please take R1D2 extra code in the new controller version! It is would be fine.

TP-Link took over some critical bug fixes from my script omadactl in their control.sh already, but not all improvements.

Regarding Privilege Separation, which was absent until V2.7.0, TP-Link decided to use jsvc instead of start-stop-daemon(8) or daemon(8), thus creating another dependency to a binary not really needed since it is not the Java part which needs root permissions, but just the tpeap start/stop script for starting the server on boot time.

I did run start-stop-daemon successfully for Privilege Separation with Omada Controller versions 2.5, 2.6 and 2.7, but since version 3.x this is not possible anymore because of a platform-check for Linux/Windows in in the EapMain Java class.

If TP-Link would remove this platform check in the EapMain and EapLinuxMain classes, we could still use start-stop-daemon on Debian-based platforms, which even has some useful additional features compared with jsvc. What's more, on Debian jsvc requires OpenJDK, which does not work with Omada Controller last time I checked. That's why Omada Controller doesn't run on Debian-based platforms out of the box (except on Raspbian). The jsvc utiity not only re-invents the wheel, but is - in my opinion - the wrong way to do Privilege Separation in Omada Controller. I told this TP-Link's R&D numerous times.

It seems that TP-Link R&D like Java too much and overlook how to do things in Unix/Linux the much more easy way. Don't ask me why, maybe forrest or Jonas_TP-Link can tell.

Anyway, it was hard work to convince R&D to use Privilege Separation at all, albeit it is still not done at the full extent it could be done even in latest version 3.1.13. So I gave up and still use Omada Controller V2.7.0 in the field and OC200 only for some customers who need newer functions.