My Goal is to build an openHAB installation on my Mac that is auto-starting, conformant with Mac best practice and secure!
What is the standard / best-practice directory path to place applications into on macOS systems ? (e. g. /opt/openHAB, dedicated project folder from root, e. g. /smarthome/openHAB etc.)?
What are the standard/best-practice security settings to operate openHAB on a Mac? Preferably I want to run openHAB with as tight security and least privileges as possible and not go with root rights or via sudo. Is it a good idea to create a dedicated user account that is reserved for running openHAB? Do I have to apply specific rights to the openHAB directory folder?
You best bet to answer this is on a Mac forum. It’s BSD based which shares a lot in common with Debian Linux but some quick looking showed no mention of /opt/ for BSD so I don’t know what the best place. Ultimately it probably doesn’t matter all that much. I’d use /opt out of habit.
Same as Linux. Create a system user with no shell. Obviously, the openhab users will need read/write permissions on all of it’s files.
Well, if that thread didn’t get any answers or replies I’m not sure reposting the same question is going to give you any additional information. Your best bet is to ask on a Mac forum for how to start a Java process as a service on a Mac. Only a tiny minority of OH users run OH on a Mac so there isn’t a lot of people to provide support.
There is a link at the bottom of the page that will take to straight to the page where you can make modifications and submit a PR.
Well, it was a long slog but I finally put bits and pieces together the allow running openHAB as a service on Mac Catalina (10.15.2) on my mac mini. I put this together from several posts from stackoverflow, here, and elsewhere.
This deserves a better explanation and more step-by-step instructions, but until I’m convinced there’s more than two of us trying to do this I am not going to invest the time.
There are three things I needed to do to be successful:
configure the openhab folder to a good place and with the right permissions so that it can be run as a daemon on Mac
Generate the install-service in openhab, and then fix the bugs in it
Add user and group to the launchd openHAB.plist and launch it.
Details of the specific steps I used: (Note that steps 1-3 and step 6 are recommended, but not required. Otherwise the daemon will run as root, which is not a good practice but which will certainly work)
Create an _openhab non-login user and group to run the service. This is beyond the scope of this article, but this serverfault article has a good treatment and a script you can modify to create it.
Download openhab (I used 2.5.1) and extract the openhab-2 folder
move the openhab-2 folder to /opt/openhab
change owner of the openhab folder
sudo chown -R _openhab:_openhab /opt/openhab
Run openhab in terminal
When you get the openhab prompt, then type install-service to generate the service wrapper files, and then logout to stop openhab.
Edit the generated /opt/openhab/runtime/bin/openHAB.plist and add these two entries near the bottom of the file, just above the </dict> line: <key>UserName</key> <string>_openhab</string> <key>GroupName</key> <string>_openhab</string>
Use the commands printed by install-service to move the openHAB.plist to /Library/LaunchDaemons and update permissions as mentioned in the output from the install-service command. Don’t try to start it yet.
fix the faulty output from the openhab:install-service command with the next several lines
Run /usr/libexec/java_home -v1.8 and copy the resulting directory. For me it’s
open /opt/openhab/runtime/bin/openhab-service in a text editor (I used BBEdit, TextEdit is not a good choice). Edit the first (non-comment) line so that it has the correct JAVA_HOME and then save the file, e.g.
you’re now done working around openhab:install-service bugs
Use launchctl start openHAB to start the service and try to log in.
If you have problems try setting wrapper.console.loglevel=DEBUG in /opt/openhab/userdata/etc/openHAB-wrapper.conf and try starting it again. The /opt/openhab/userdata/logs/wrapper.log file may have useful info in it then.
Also, LaunchControl is an excellent tool for debugging, working with, and visualizing LaunchDaemons and LaunchAgents.
Thanks for this! Trying to do the same thing. I’m sure a lot of Mac users are interested.
I followed your guidelines, but nothing happens. No entries in wrapper.log. LaunchControl suggests it might be a permissions problem. Did you only chmod the directory /opt/openhab or also all files and subdirectory within?
@robwbartel, I had no luck installing the service under a system user, like you did. In the end I did manage to install it under LaunchDaemons without the addition to the plist file in step 6. Openhab runs as a daemon now, as root I guess. Not ideal. Basically I followed your steps except for steps 1,2,3 and 6.
Did you report the bugs you found (steps 9-13)?
Would make optional steps 1-3 and 6 a good addition to the installation documentation?
Unfortunately it does not work and I have no idea where to search for the root cause.
The launch daemon fails with following error message:
Running openHAB runtime...
wrapper | --> Wrapper Started as Console
wrapper | Launching a JVM...
wrapper | JVM exited while loading the application.
jvm 1 | NOTE: Picked up JDK_JAVA_OPTIONS: --add-reads=java.xml=java.logging --add-exports=java.base/org.apache.karaf.specs.locator=java.xml,ALL-UNNAMED --patch-module java.base=lib/endorsed/org.apache.karaf.specs.locator-4.2.7.jar --patch-module java.xml=lib/endorsed/org.apache.karaf.specs.java.xml-4.2.7.jar --add-opens java.base/java.security=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.naming/javax.naming.spi=ALL-UNNAMED --add-opens java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
jvm 1 | Error occurred during initialization of VM
jvm 1 | Cannot specify java.base more than once to --patch-module
... repeated 4 times ...
wrapper | There were 5 failed launches in a row, each lasting less than 300 seconds. Giving up.
wrapper | There may be a configuration problem: please check the logs.
wrapper | <-- Wrapper Stopped
Obviously some Java config seems to be broken, but the error message is chinese for me.
Any hints what to check?
When starting openhab via the start-script (start.sh), it works from the same location.
I put everything into /usr/local/opt/openhab
This seems to be caused by the wrapper picking up the non-wrapper JDK args - if you look in openHAB-wrapper.conf file you’ll see a line starting set.JDK_JAVA_OPTIONS=, and it looks like much (all?) of what that specifies is repeated further down in the wrapper.java.additional._n_= lines. If you look at the wrapper output you’ve quoted you can see it’s telling you it picked up the JDK_JAVA_OPTIONS, and it’s then adding on the wrapper options, the net result being that the --patch-module lines occur twice. I’ve simply commented out the JDK_JAVA_OPTIONS line from my own config and it seems to work ok, but I’ll not swear to this being the correct answer.