After 5 years of going back & forth, I’ve decided to give up on trying to complete the OpenNMS ports for FreeBSD and dropped maintainership of the Java dependencies in the ports tree (net/jicmp, net/jicmp6, databases/jrrd, databases/iplike)
There are some issues which are show stoppers that need addressing upstream
- Separation of configuration & user data from the location of application binaries, Initially I began patching the source to look for files in a different location to the default so that things would integrate with the user land correctly but it soon became apparent that the patching would be a nightmare to maintain on an ongoing basis due to the number of patches required per configuration file. It was clear that things would need to be dealt with at the source rather than patched post release, a long running discussion with developers, bug reports raised, some (minor) patches submitted, 4+ years on, still ignored due to a lack of interest.
- Dynamically generated filenames, inherited from Google Web Toolkit, every build attempt generates new filename which make packing impossible.
Update OpenNMS developer Benjamin Reed points to a possible fix
- Unreliable build process, maven fails between 2 to 3 times minimum which would cause lots of false alarms in an automated build environment e.g. the freebsd build cluster.
This is somewhat of an improvement from a few years back where it would not be possible to build because repositories were not available for a day or two.
As it stands, the port is a shell which make it easy to install OpenNMS on FreeBSD but has major issues when it comes to upgrades or uninstallation. It’s best install dependencies from ports & install OpenNMS manually.
I’ve been working on getting CoovaChilli running on FreeBSD 10 the past few weeks. The first problem was that the source code would not build. FreeBSD 10 shipped with clang instead of GCC as the default compiler which is not as forgiving as GCC, clang flagged up lots of issues with the code base such as lack of parameters for functions, one change needed which was a shortcoming of clang itself was the lack of support for nested functions.
The other problem was that CoovaChilli was using a structure that had been marked as deprecated in Net/Free/OpenBSD/Darwin for quite some time & with the release of 10.0, FreeBSD removed this structure from their codebase. This resulted in the
tun(4) interface being initialised but no IP address being assigned to it, which was interesting, dhcp responses were still going out but obviously nothing could talk back to the IP address that coova was configured to be listening on (
All BSDs & derivatives were separated out from Linux in
dev_set_address(), Linux was set to use the pre-existing method & the BSD & derivatives were switch to use the “new”
With these change, it’s possible for a client connected to a router running CoovaChilli to visit sites listed in
uamallowed. These are sites which CoovaChilli allows to be browsed without needing authentication through the captive portal first. Next stage is to get the captive portal running along with a RADIUS server so that the previous revision of the setup guide can be updated. With the release of FreeRADIUS 3 configuration has changed somewhat, hence the old documentation for version 2 doesn’t necessarily apply.
These changes so far only allow the code to build without any features enabled, for example, enabling OpenSSL support yielded more errors which have not been fixed yet & I suspect others will show up as more options are switched on.
The work so far can be found here
I’ve written a port for Chillispot based on the patch submitted to the Chillispot mailing list today by Steve Davies.
You can grab a copy of it here