Omada Controller 3.0.2 for Linux (including new tpeap v1.4)
Update 2020-04-30: Omada EAP Controller 3.2.10 community version has just been released.
There is now a .deb-package available for easy installation on Debian, Raspbian and any other Debian-based Linux. The steps below are not necessary anymore for the installation of Omada Controller using the dpkg package manager.
The following (now obsolete) post is still here for reference only:
Hello world!
TP-Link just released the latest version of Omada Controller 3.0.2. Thanks to a tip from forum user humor_amarillo I got my hands on it early. So here it is, baked in just no time: The community version of
Omada EAP Controller 3.0.2 for Linux
Last update: 2018-08-28 22:40
What's new in this version?
- Cloud support. See the official release notes on the TP-Link website.
- Auto-backup, but the Windows-way. See below for the Linux-way to do backups.
- From what I saw so far, the directory structure has been cleaned up. Photoshop file with icons from v2.7.0 has been removed from the images directory.
- GUI now seems much more cleaner, too. Well done, TP-Link!
- EAP Controller starts ~30% faster compared with v2.7.0.
- All steps in the initial wizard now can be skipped! Finally my feature request was honored, thanks to R&D very much!
What's new in the Linux release?
- Logo now shows »Community version« below the TP-Link logo, so you can recognize it better.
- Two new options for tpeap:
- dump lets you dump the database as well as the maps and keystores.
- restore lets you restore a database dump including maps and previous keystores.
- A surprise (see below).
Update #1: New tpeap 1.4 has been released (see this post for more details).
For your convenience, I have attached the new tpeap script v1.4 to this posting, too. It might be handy for doing a backup of your v2.7.0 installation, which can be easily restored in EAP Controller 3.0.2.
Update #2: The tpeap 1.4 just has been added to the TAR archive with Omada Controller 3.0.2. If you download the TAR archive as described below, you will get the new tpeap script already - no need to install it twice.
Standard disclaimer, as usual: Use at your own risk.
This community version (cv for short) is neither released nor supported by TP-Link and it still needs some testing.
Installation of the Linux version
— If you want to install the Linux version for the first time, please see this post first, replace the instructions in step 2 there with the instructions in the same step 2 in this post below and proceed with the remaining steps here when you have installed all the pre-requisites (eapc role account, Java JRE, mongodb database).
— If you already have installed Omada EAP Controller 2.7.0cv on your Linux system, just read on.
Step 1: Make a backup
Obviously, to make a backup, the old EAP Controller needs to be running. Download the tpeap script attached to this posting and install it (you can safely overwrite the old tpeap version in the 2.7.0cv Controller):
cp tpeap /opt/tplink/EAPController/bin/
Next, create a backup. You need to specify a directory for the database dump (else it uses the directory EAPC_HOME/backup):
tpeap dump /tmp/backup
tpeap will create the directory, copy your maps and keystore to it, and then execute mongodump, which dumps the database in binary BSON format into the backup archive. Now you can safely stop the EAP Controller.
Step 2: Download and extract the software
Download the TAR archive from https://rent-a-guru.de/ftp/eapc-3.0.2.tar.gz
Check the SHA256 sum:
$ sha256sum -b eapc-3.0.2.tar.gz
2b9c9ce54a3bc698b25901f1234aef79e3d1e51703a9af1dcaa8360c4b407f66 *eapc-3.0.2.tar.gz
9638bb2ed43d58169a33b52ea2be1d48482fae68a5d93028f162ff66f2b0c4ea *eapc-3.0.2.tar.gz
$
Step 3: Set up the EAP Controller
Installation is straight-forward: Extract the TAR archive as root in /opt/tplink, remove the symlink EAPController pointing to version 2.7.0cv and create a new one pointing to the EAPController-3.0.2 directory just extracted from the TAR archive. Easy, isn't it?
cd /opt/tplink
tar xvzf /your-download-dir/eapc-3.0.2.tar.gz
rm EAPController
ln -s EAPController-3.0.2 EAPController
Do a quick check wether the permissions and ownership has been set correctly (complete dialog shown here):
# ls -ld /opt/tplink/EAPController-3.0.2
drwxr-xr-x 13 eapc eapc 4096 Aug 21 05:53 /opt/tplink/EAPController-3.0.2
# ls -l /opt/tplink/EAPController-3.0.2
total 12
drwxr-xr-x 2 root root 6 Aug 21 05:27 backup
drwxr-xr-x 2 root root 55 Aug 21 02:11 bin
drwxr-xr-x 6 eapc eapc 55 Aug 21 05:53 data
drwxr-x--- 2 root eapc 39 Aug 21 01:30 keystore
drwxr-xr-x 2 root root 4096 Aug 21 01:30 lib
drwxr-xr-x 2 eapc eapc 58 Aug 21 05:53 logs
drwxr-xr-x 2 root root 22 Aug 21 03:18 man
drwxr-x--- 2 root eapc 4096 Aug 21 01:30 properties
drwxr-xr-x 2 root root 36 Aug 21 05:36 webapps
drwxr-xr-x 3 eapc eapc 32 Aug 21 05:53 work
#
Two more things: Install the symlink to the Java JRE:
cd /opt/tplink/EAPController
ln -s /where-your-JRE-lives/ jre
and the manpage of tpeap (you find it in the man subdirectory):
cp man/tpeap.man /usr/share/man/man8/tpeap.8
gzip -v --best /usr/share/man/man8/tpeap.8
My JRE resides under /opt/jvm, so it looks like this:
# ls -l jre
lrwxrwxrwx 1 root root 21 Aug 21 05:53 jre -> /opt/jvm/jre1.8.0_181
Important note for users of Ubuntu and probably other distros, too:
If your mongodb version is >= 3.6 you need to edit the argument list EAPC uses to start the mongod daemon. The option --nohttpinterface, which is set by EAPC, has been removed in mongodb version 3.6 and newer.
Find out your mongod version:
mongod --version
To get rid of the --nohttpinterface option, you will have to delete it from the file mongodb.properties:
cd /opt/tplink/EAPController/properties
cp mongod.properties ../mongod.properties.ORIG
sed -i 's/^\(eap.mongod.args=.*\) --nohttpinterface \(.*\)$/\1 \2/' mongodb.properties
Of course, you can use any other editor, too.
Last step: fire up the new Controller
tpeap -w start
Now restore the database saved in step 1:
tpeap restore /tmp/backup
Enjoy!
Uh, and if you want to see what probably comes next to a Linux server near you:
The color-intense theme awesome with FontAwesome icons - no more image files needed, clean layout for EAPC 2.7.0cv.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
E-raser wrote
I also get "General Error"
Fresh install didn't solve it :-(
That's mysterious. A general error is thrown when something unforeseen, unspecific happens. Can't imagine what could go wrong with a simple TCP connection via HTTPS into the Cloud (AWS) ... Have you already tested binding with another browser or from a network with another Internet connection? Did you check for possible Javascript errors when loading the web UI pages?
- Copy Link
- Report Inappropriate Content
Tested with other browsers -> same problem
Can't find any javascript errors on loading page
server has several connections to AWS without any problem
In my logs when I enable disable/enable cloud & try to bind I get:
--> Stop
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[CloudClient.java:194] - CloudClient is stopped.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:147] - Cloud service is stopped.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:91] - Stopping PF module.
2018-08-26 10:24:10 [Thread-33] [INFO]-[SourceFile:526] - cleanExpiredCacheThread is interrupted.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:547] - Clean expired cache thread is destroyed.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:180] - Stopping SCMP Server.
2018-08-26 10:24:10 [Thread-34] [INFO]-[SourceFile:393] - handleRequestThread is interrupted.
2018-08-26 10:24:10 [Thread-34] [INFO]-[SourceFile:433] - SCMP request handle thread is ended.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:449] - SCMP request handle thread is destroyed.
2018-08-26 10:24:10 [qtp232307208-127] [INFO]-[SourceFile:131] - clear proxy connection info
--> Start
2018-08-26 10:24:22 [qtp232307208-127] [INFO]-[SourceFile:80] - Starting PF module.
2018-08-26 10:24:22 [qtp232307208-127] [INFO]-[SourceFile:155] - Starting SCMP Server.
2018-08-26 10:24:23 [qtp232307208-114] [INFO]-[SourceFile:189] - Request tries to trigger CloudClient to recover connection.
2018-08-26 10:24:23 [qtp232307208-114] [WARN]-[SourceFile:94] - [Exception]execution(OperationResponse com.tp_link.eap.monitor.cloud.clouduser.service.impl.CloudUserServiceImpl.bindDeviceOwner(ControlType,JSONObject))[exception message:null]
Grtz,
E-raser
- Copy Link
- Report Inappropriate Content
Seems to have to do with the user name/TP-Link ID. What happens if you create a new TP-Link ID with a different mail address and use this to bind?
- Copy Link
- Report Inappropriate Content
Also tested -> same problem
Grtz,
E-raser
- Copy Link
- Report Inappropriate Content
If it's just an ID for tests and if you want, I can try to bind an Omada Controller running on a spare system to it, just to see if it works.
If I should test, just send the ID/PW by private mail.
- Copy Link
- Report Inappropriate Content
check PM
Grtz,
- Copy Link
- Report Inappropriate Content
Seems like tpeap restore doesn't work?
root@jalapeno:/opt/tplink/EAPController# tpeap restore /tmp/backup
Restoring database from dump in '/tmp/backup'
2018-08-28T11:52:31.914-0400 preparing collections to restore from
2018-08-28T11:52:31.914-0400 don't know what to do with file "/tmp/backup/tpeap/accessSubentGroup.bson", skipping...
2018-08-28T11:52:31.914-0400 don't know what to do with file "/tmp/backup/tpeap/accessSubentGroup.metadata.json", skipping...
- Copy Link
- Report Inappropriate Content
miked315 wrote
Seems like tpeap restore doesn't work?
root@jalapeno:/opt/tplink/EAPController# tpeap restore /tmp/backup
Restoring database from dump in '/tmp/backup'
2018-08-28T11:52:31.914-0400 preparing collections to restore from
2018-08-28T11:52:31.914-0400 don't know what to do with file "/tmp/backup/tpeap/accessSubentGroup.bson", skipping...
2018-08-28T11:52:31.914-0400 don't know what to do with file "/tmp/backup/tpeap/accessSubentGroup.metadata.json", skipping...
Note that tpeap just executes mongodump to create a dump and mongorestore to restore it. It does not do the real work for itself.
From which version of Omada/EAP Controller did you restore to which other version (if any)?
- Copy Link
- Report Inappropriate Content
It was a backup from 2.7.0 using mongod v3.6.3 on Ubuntu. I ended up stopping 3.0.2 and copying over /data from 2.7.0 into 3.0.2 and then starting it back up and everything came up perfectly.
EDIT: I should note, for anyone following along that may attempt the same thing, I had to delete the /data directory from 3.0.2 first and then copy over the old 2.7.0 /data directory. Originally I tried copying the 2.7.0 /data on top of 3.0.2 after it had been started up and was sitting at the wizard screen when accessing the web interface, this did not work at all, the controller would not start up. Also for reference purposes, the 2.7.0 /data was a fresh install created on 2.7.0 with the Ubuntu package of mongod v3.6.3.
- Copy Link
- Report Inappropriate Content
miked315 wrote
It was a backup from 2.7.0 using mongod v3.6.3 on Ubuntu. I ended up stopping 3.0.2 and copying over /data from 2.7.0 into 3.0.2 and then starting it back up and everything came up perfectly.
I see. Maybe the file just was unused in 3.0.2 due to changed DB layout (I couldn't locate it in a dump made with mongodump, maybe it's gone). Anyway, copying over the data directories is the preferred way to transfer settings from one version to another version for me, too. Omada Controller will then add any new collections and ignore old ones silently, while mongorestore prints a warning in such cases.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 9
Views: 59363
Replies: 109