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

Attachment: openhab_4.tgz
Description: application/gtar-compressed

Reply via email to