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?
> 
> 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
> >> >
> >>
> >>
> >
> >
> >
> 
> 

-- 
V/r,

Charlie

Reply via email to