goertzenator wrote 

1. The only way I can see to grab tarballs is from link on https://www.tp-link.com/us/support/download/omada-software-controller/ .  Is there a better place to grab this program?

 

2. I see in another thread that people are running v4 on linux... where is this coming from? (I do not see v4 for linux at the above url).

1) No. The TAR archive at the linked site is the official version from TP-Link.

2) How about this post (3rd from top of this subforum)?

However, as I understand NixOS uses its own package manager. Can this package manager process .deb packages?

goertzenator wrote

So is "ftp.rent-a-guru.de" the authoritative source for community packages?

It's the source for this particular package which I call »Community Version (CV)« b/c it's from me (community member) to you, the reader (also a community member) made available on my FTP server. :-)

There is also at least one up-to-date docker image maintained by community member Ronald1965  which is hosted in the docker repository.

Are these repacks of the official versions or is there another source?

Yes, it is the official Java code re-packed to a .deb package. See the first post in the linked thread, at the end of the post you find a note describing the differences between the official and the CV package. This are not really different »versions«, since the Omada Java classes are always based on the same, official version which is proprietary code owned by TP-Link. One cannot get the sources for this software.

Reason for the re-packaging was a serious root expoit in the Java code due to missing Privilege Separation, wrong file permissions, bugs in the start/stop script and bundling with old binaries in the official versions of former EAP Controller V2.4 and V2.5 for Linux/Windows and V2.6, which back then was available for Windows only.

Since bug fixes did last way too long for my business, I created a V2.6 for Linux by using the Java classes from the official Windows package, adding Privilege Separation to mitigate against root privilege escalation, correcting file ownerships and by removing bundled binaries to make the package architecture-independent.

This V2.6 CV came out long before next official version for Linux, which was V2.7 (this official release did skip V2.6 silently, but still had all mentioned bugs from V2.4). You can find the gory details in several old posts here in the forum.

Starting with version V3.0 of the – meanwhile renamed – Omada Controller TP-Link added some of the enhancements from the community version V2.6 to the official version, e.g. Privilege Separation and some critical bug fixes in the start/stop script. This was the first official version which eventually solved the Java privilege escalation bug.

With the release of Omada SDN Controller V4.1.5 the official version also removed previously bundled binaries (JRE8, mongodb).

Current community version 4.1.5 fixed two bugs with pathnames in Java property files, which in the official release will be fixed in the next release. Also, the management script omadactl is present only in the community version. Another enhancement of the CV is omadactl's feature to switch between different versions of Omada Controller, which can be installed at the same time. This was temporarily removed in V3, but added again for V3/V4 controllers with the release of V4.1.

@goertzenator, unfortunately you can't base a Linux version on Windows Java classes anymore since V3.0.1. Reason is that there are some calls identifying the OS the controller runs on. Windows Java classes won't start at all on a Linux server.

I recommend yoy take the latest CV as a starting base. If you don't trust the copies of official Java files in the CV, you can replace them by the Java classes from the official Linux version – but that would be a huge waste of time since they are byte for byte identical.

Also better use the existing omadactl rather than building your own (you would need a profound Linux knowledge and experience to do so). But much more important is the UNIX/Linux principle of not re-inventing the wheel again and again. omadactl is a portable shell script, thus comes as open source, can be audited for bugs by everyone and should run on NixOS, too. Historically, the community version of omadactl (former name: tpeap) was needed b/c official control.sh/tpeap scripts did lack essential functions.

Next reason to use omadactl is that it still supports Privilege Separation for older controller versions (some users still need to run controller version V2.7 for management of EAP120/220) and the fact that omadactl allows to switch between different versions of Omada Controller installed at the same time.

If you insist to re-invent the start/stop script, I recommend to base it on control.sh from the official version as a blue-print.

Only thing I will never ever support in the CV are native systemd scripts (see »reinventing the wheel« if you wonder why). Rather I urge people to switch over to systemd-free Devuan (https://devuan.org) instead of jumping on the systemd train, which IMO is the gravedigger of the UNIX philosophy if not the whole Linux OSS scene at all.