On 1/9/24 18:29, Chaz Kettleson wrote: > On Wed, Jan 10, 2024 at 12:01:59AM +0300, Kirill Bychkov wrote: >> On Tue, January 9, 2024 23:22, Chaz Kettleson wrote: >> Hi, >>> On Sun, Jan 07, 2024 at 05:04:57PM +0000, Stuart Henderson wrote: >>>> 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 >>> Thank you! This is _much_ cleaner. I've been playing with this the last >>> few days incorporating your feedback. The challenge now is that all of >>> the configuration for openHAB happens through environment variables. >>> This got a little messy in the rc file, for example, setting >>> OPENHAB_HTTP_ADDRESS=127.0.0.1. Having users edit the rc file to control >>> the program seemed wrong. I looked at the installation on debian and >>> noticed they provide a /etc/default/openhab for configuration that is >>> sourced via systemd or init.d. >>> >>> https://github.com/openhab/openhab-linuxpkg/blob/main/resources/etc/default/openhab >>> >>> My approach now is to provide this file for configuration and source it >>> from the rc file. I will also update this to have 127.0.0.1 set by >>> default. I have two questions: >>> >>> 1.) OpenBSD doesn't typically have a /etc/default/, I was considering >>> just using /etc/openhab.conf thoughts?
I suggest making a /etc/openhab folder and installing the file with the variables there, as generally java programs come with quite a few config files. Make sure to add a .sh extension so users can understand what syntax to use (a small comment in there about why the file exists would be good too). A few ports that come to mind which do something similar to what you are trying to do Solr - https://cvsweb.openbsd.org/ports/textproc/solr/ Jitsi - https://cvsweb.openbsd.org/ports/net/jitsi/ Keycloak - https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/security/keycloak/ Cheers, Aisha >> We usually install sample configs to >> ${PREFIX{/share/examples/portname/sample.config and add @sample marker in >> PLIST to ${SYSCONFDIR}/portname/port.cfg. Take a look at >> /usr/ports/net/tor/pkg/PLIST >> >>> 2.) I've had a heck of time trying to get this copied there in >>> do-install. I'm a bit confused on how to use PREFIX and get the PLIST >>> updated during make fake/update-plist. For example something like cp >>> ${FILESDIR}/openhab.conf ${SYSCONFDIR} does not work. More on this in my >>> next comment. >> The answer is above. Just make sure your port is looking for a config in >> /etc/port/port.cfg and not in /usr/local/share/examples. To place sample >> config into examples dir you could just cp it from WRKSRC to >> ${PREXIX}/share/exaples/... > Thank you, that worked. I'm able to make progress now on this part. > >>>>> 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). >>> After reviewing the linux package I've decided to breakout all of the >>> directories based on the default locations openHAB defines. I think this >>> will be more natural for users anyway. Here is an excerpt from the link >>> above: >>> >>> ######################### >>> ## OPENHAB DEFAULTS PATHS >>> ## The following settings override the default apt/rpm locations and should >>> be >>> used with caution. >>> ## openHAB will fail to update itself if you're using different paths. >>> ## Only set these if you are testing and are confident in debugging. >>> >>> #OPENHAB_HOME=/usr/share/openhab >>> #OPENHAB_CONF=/etc/openhab >>> #OPENHAB_RUNTIME=/usr/share/openhab/runtime >>> #OPENHAB_USERDATA=/var/lib/openhab >>> #OPENHAB_LOGDIR=/var/log/openhab >>> >>> So now I've been struggling with the same issue as copying >>> /etc/openhab.conf for the above locations. For example, doing something >>> like: >>> >>> cp ${WRKDIST}/userdata /var/lib/openhab >>> >>> is not going to work. I tried instead setting the PREFIX=/ and doing: >>> >>> cp ${WRKDIST}/conf ${PREFIX}etc/openhab >>> cp ${WRKDIST}/userdata ${PREFIX}var/lib/openhab >>> cp ${WRKDIST}/runtime ${PREFIX}usr/share/openhab/runtime >>> >>> but the fake framework does not update the PLIST. Setting >>> PREFIX=/usr/local works for things like share/openhab, but I'm not sure >>> how to handle when things are supposed to go to /usr, /etc, /var. I've >>> reviewed documentation several times and clearly missing something. I >>> intend to clean it up once I get it working correctly (i.e. using >>> variables or even sourcing the files/openhab.conf to bootstrap locations >>> to copy to). >>> >>>> 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). >>> Done. >>> >>>> 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). >>> I've looked into this deeper. The scripts need some seatbelts because >>> there is time to spin up and shutdown the framework. It looks like this >>> was handled in the init scripts for debian. I'll plan to port this over >>> to the rc file on the next iteration. >>> >>> https://github.com/openhab/openhab-linuxpkg/blob/main/resources/etc/init.d/deb/openhab >>> >>>> 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) >>> I fixed all this. There was an odd situation where changing the >>> owner/group resulted in files being 444 for certain subdirectories. For >>> example the /var/openhab/userdata/etc directory had all files marked >>> 444, but when the owner/group was not set it copied them over with >>> correct permissions. I don't know if this is a protection when >>> @owner/@group are set to default to 444 or an issue in the ports >>> framework. Setting @mode fixed this, but I was surprised it didn't >>> inherit the permissions from the tgz. Now all files are owned by root >>> except those that will change during runtime. I did some testing to find >>> out what broke and modified it manually. I didn't excercise every >>> function of openHAB so there will likely be more to change with future >>> testing. >>> >>> Thanks again for taking the time and helping during this process. >>> >>>> >>>> >>>>> -- >>>>> 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 >>>>> >>>> >>> >>> >>
