Restore setting on first omada controller startup
Feature request:
1) It would be perfect if user can restoring previously omada controller config on first new controller startup.
2) ARM adobted deb package for raspberry pi distro
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
1) yes, i can copy data directory but it is not user frandly.... Unifi controller has it
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...
and its also feature request...need to strive for the best and now "the best" is unifi controller
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
R1D2,
1) I mean first controller start after first install. After the first start, the controller offers to configure it, but does not offer to restore the configuration from a file. Yes, i can create fake config and then restore config or copy data directory to new controller directory but these are extra iterations
2) Many thanks for your work with controller adoptation for Raspi and i agree with you about competition with OC200.
My controller works perfect with 3 access point on Raspi.
- Copy Link
- Report Inappropriate Content
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!
- Copy Link
- Report Inappropriate Content
Many thanks! You are an enthusiast! Your .deb package will help many people with raspi and tplink point.
But the TPLINK as creators of the product should do this work automatically.
I have already updated my controller to latest version.
It is my manual:
1) Stop existing controller sudo tpeap stop
2) Copy data directory from existing controller /opt/tplink/EAPController to other backup folder
3) run /opt/tplink/EAPController/uninstall.sh to unistall controller
4) cd /home/pi and wget https://static.tp-link.com/2019/201905/20190527/Omada_Controller_v3.1.13_linux_x64.tar.gz
5) tar -zxf Omada_Controller_v3.1.13_linux_x64.tar.gz
6) rm Omada_Controller_v3.1.13_linux_x64/bin/mongod
7) ln -s /usr/bin/mongod Omada_Controller_v3.1.13_linux_x64/bin/mongod
8) sed -i -e 's/JRE_HOME="${OMADA_HOME}\/jre"/JRE_HOME="\/usr\/lib\/jvm\/default-java"/g' Omada_Controller_v3.1.13_linux_x64/bin/control.sh
9) sed -i -e 's/JAVA_OPTS="-server/JAVA_OPTS="-client/g' Omada_Controller_v3.1.13_linux_x64/bin/control.sh
10) sed -i -e 's/${PORTT_TOOL} 127.0.0.1 ${HTTP_PORT} 500/netstat -plnt | grep :::${HTTP_PORT}/g' Omada_Controller_v3.1.13_linux_x64/bin/control.sh
11) sed -i -e 's/OMADA_USER=${OMADA_USER:-root}/OMADA_USER="eapc"/g' Omada_Controller_v3.1.13_linux_x64/bin/control.sh
12) sed -i -e 's/chmod 755 ${INSTALLDIR}\/jre\/bin\/\*/chown -R eapc:eapc ${INSTALLDIR}/g' Omada_Controller_v3.1.13_linux_x64/install.sh
13) cd ~/Omada_Controller_v3.1.13_linux_x64/ and run ./install.sh
14) Stop new controller sudo tpeap stop
15) Copy data directory from backup folder (2) to the new data folder /opt/tplink/EAPController
16) sudo tpeap start
I followed the instructions on https://dreambyte.nl/2018/12/27/installing-eap-controller-on-raspberry-pi/
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
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.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 7919
Replies: 9
Voters 0
No one has voted for it yet.