On 2024/01/07 01:15, Chaz Kettleson wrote: > Hello, > > This is my first port. I'm looking for mentorship, testing, and feedback > to eventually get this committed. I've read the porting guide, > bsd.port.mk(5), rc.subr(8), and login.conf(5) when making this port. > > This is a port for open Home Automation Bus https://www.openhab.org/. > From the project github and DESCR: > > The open Home Automation Bus (openHAB) project aims at providing a > universal integration platform for all things around home automation. > It is a pure Java solution, fully based on OSGi. > > It is designed to be vendor-neutral as well as hardware/protocol-agnostic. > openHAB brings together different bus systems, hardware devices, > and interface protocols by dedicated bindings. These bindings send > and receive commands and status updates on the openHAB event bus. > This concept allows designing user interfaces with a unique look&feel, > but with the possibility to operate devices based on a big number > of different technologies. Besides the user interfaces, it also > brings the power of automation logic across different system > > I had a few challenges when making this port. > > Firstly, there is no archive root when extracting the distfile. Initially > I had set ${WRKDIST}=${WRKDIR} and had do-install copy everything from > ${WRKDIST}. This turned out to be a problem with 'make fake' since it was > recursively trying to copy fake-amd64. I eventually opted to override > EXTRACT_CASES for tar.gz to create a subdir and extract there. I was hoping > for a variable that might let me set a directory instead, but I imagine most > distfiles extract with an archive root. > > Secondly, I considered using the javaPathHelper within the rc file, but > ultimately opted to use the scripts that come with Apache Karaf. The > start.sh packaged with openHAB just calls these under the hood. They do > a lot of bootstrapping for the environment, so calling java directly > would cause a number of issues. Unfortunately, these scripts rely on > the JAVA_HOME environment variable to be set. I packaged a openhab.login > so I could set this variable via setenv. I was hoping the packaging process > would allow me to substitute build variables similar to the rc file. This > way > I could do something like: > > :setenv=JAVA_HOME="$(${LOCALBASE}/bin/javaPathHelper -h openhab" > > I quickly realized it wasn't doing it when $ was substituted for the user > per login.conf(5) and copied verbatim. This left me no choice but to > hard-code the path (perhaps logic could be added for this case?)
Here it is with a few tweaks; - handling extraction and JAVA_HOME in a bit more of a simple way, no need for login.conf - no need for a separate OPENHAB_HOME, we can just point PREFIX there - don't repeat the name in COMMENT (where it's shown, PKGNAME is shown too, so that's redundant information), instead try to provide more of a brief description > Lastly, it's possible to patch this to break out configuration to /etc, > logging to /var/log, as well as the data, cache, state, etc -- however, > most Karaf-based applications don't typically change these, and most other > Java-related ports I've looked at didn't either. This was mostly done > for myself as I'm an experienced Java developer looking to contribute to > openHAB (and use it!), however, I'm happy to make any changes to how it's > installed based on feedback. Some thoughts: I think it probably would be helpful to at least put logs under /var/log (perhaps with @sample /var/log/openhab and correct ownership, and install a symlink as part of the package i.e. /var/openhab/userdata/logs -> /var/log/openhab, which should avoid the need to patch anything). It could do with a pkg-readme (formatting based on the template under /usr/ports/infrastructure/templates/README.template) at least indicating that by default it runs with the web interface accessible to the world on port 8080 and allows anyone with access to that to carry out the initial setup. (If it's not too hard to do, it might be better to restrict that to 127.0.0.1 by default and give info about how to change it; if the web interface port can be changed it would be helpful to show how to do that too, as 8080 is pretty often used by other software). Stopping the daemon doesn't seem to work very reliably. In particular after I figured out that 8080 was conflicting and I stopped the other daemon to test, "rcctl restart openhab" didn't stop/restart/get it to pick up new config. I think I'd be happier to at least remove rc_check and construct some pexp string to match. Not sure if that might also be preferable for rc_stop (it didn't seem to respond all that well to signals either - at least if pexp is set then the fallback that rc.d uses for timeouts should kick in). The package installs all files as writable by _openhab - that should be ratcheted down so that only files/dirs which need to be changed at runtime are writable the daemon user, otherwise have them owned by root. But also, some places which the daemon tries to write to aren't writable (need a dir creating with @sample perhaps?) 2024-01-07 16:39:58.803 [ERROR] [ficate.internal.CertificateGenerator] - Failed to generate a new SSL Certificate. java.security.cert.CertificateException: Failed to generate the new certificate. [...] Caused by: java.io.FileNotFoundException: /var/openhab/userdata/etc/keystore (Permission denied) [...] and java.io.FileNotFoundException: /var/openhab/userdata/etc/users.properties (Permission denied) > -- > Chaz > > Index: user.list > =================================================================== > RCS file: /cvs/ports/infrastructure/db/user.list,v > retrieving revision 1.436 > diff -u -p -r1.436 user.list > --- user.list 5 Jan 2024 14:40:32 -0000 1.436 > +++ user.list 7 Jan 2024 04:58:41 -0000 > @@ -404,3 +404,4 @@ id user group port > 893 _azorius _azorius www/azorius > 894 _gonic _gonic audio/gonic > 895 _soju _soju net/soju > +896 _openhab _openhab misc/openhab >
openhab,2.tgz
Description: application/tar-gz
