On Sat, Feb 10, 2024 at 05:57:40PM -0500, Chaz Kettleson wrote: > On Wed, Jan 10, 2024 at 12:53:18AM -0500, Chaz Kettleson wrote: > > > > On Wed, Jan 10, 2024 at 12:15:39AM -0500, Chaz Kettleson wrote: > > > > > > On Tue, Jan 09, 2024 at 10:24:43PM -0500, A Tammy wrote: > > > > > > > > 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 > > > > > > > > > > Thanks. I updated the package README to indicate how /etc/openhab.conf > > > is used. > > > > > > > > > > > >> 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 > > > > >>>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >> > > > > > > > > > > Here is the latest interation for comments/feedback. I'd still like to > > > break out to /var/lib/openhab/{conf,userdata} for > > > ${WRKDIST}/{conf,userdata} but getting the fake framework and PLIST was > > > still proving a challenge. I'm also working on fixing restart (need > > > seatbelts around start/stop since the wrapper scripts don't produce the > > > pid until they complete). Everything else should be updated based on > > > feedback. > > > > > > Thanks again for all the help. > > > > > > -- > > > V/r, > > > > > > Charlie > > > > Wrong PLIST, please use this version. > > > > -- > > Chaz > > > > All, > > I believe I have addressed all issues in this latest version. Requesting > additional testing and to have this added to misc/openhab! > > OK? > -- > V/r, > > Charlie
ping -- Chaz
