Exec binding and echo, netcat, a pipe, carriage return and quotation marks

Look one folder up, in /etc/openhab

Genius

Just 2 folders in /etc/openhab/ configurations and jetty

and it’s still not showing up in the browser. I’m baffled…

Here is the contents of my logback.xml. OH was installed via apt-get on an Ubuntu machine, though that shouldn’t matter.

<configuration scan="true">

        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
                <encoder>
                        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}] - %msg%n</pattern>
                </encoder>
        </appender>

        <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>${openhab.logdir:-logs}/openhab.log</file>
                <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                        <!-- weekly rollover and archiving -->
                        <fileNamePattern>${openhab.logdir:-logs}/openhab-%d{yyyy-ww}.log.zip</fileNamePattern>
                        <!-- maximum number of archive files to keep -->
                        <maxHistory>30</maxHistory>
                </rollingPolicy>
                <encoder>
                        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}] - %msg%n %nopex</pattern>
                </encoder>
        </appender>

        <appender name="EVENTFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>${openhab.logdir:-logs}/events.log</file>
                <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                        <!-- weekly rollover and archiving -->
                        <fileNamePattern>${openhab.logdir:-logs}/events-%d{yyyy-ww}.log.zip</fileNamePattern>
                        <!-- maximum number of archive files to keep -->
                        <maxHistory>30</maxHistory>
                </rollingPolicy>
                <encoder>
                        <pattern>%d{yyyy-MM-dd HH:mm:ss} - %msg%n</pattern>
                </encoder>
        </appender>

        <!--       <appender name="ZWAVEFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>${openhab.logdir:-logs}/zwave.log</file>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <fileNamePattern>logs/zwave-%d{yyyy-ww}.log.zip</fileNamePattern>
                <maxHistory>30</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}:%-4line]- %msg%n</pattern>
            </encoder>
        </appender> -->
<!--
        <appender name="NESTFILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
            <file>${openhab.logdir:-logs}/nest.log</file>
            <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                <fileNamePattern>logs/nest-%d{yyyy-ww}.log.zip</fileNamePattern>
                <maxHistory>30</maxHistory>
            </rollingPolicy>
            <encoder>
                <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}:%-4line]- %msg%n</pattern>
            </encoder>
        </appender>
-->
        <!-- Change DEBUG->TRACE for even more detailed logging -->

        <!--        <logger name="org.openhab.binding.zwave" level="DEBUG" additivity="false">
            <appender-ref ref="ZWAVEFILE" />
        </logger> -->

   <!--     <logger name="org.openhab.binding.nest" level="TRACE" additivity="false">
            <appender-ref ref="NESTFILE" />
        </logger> -->

        <logger name="runtime.busevents" level="INFO" additivity="false">
                <appender-ref ref="EVENTFILE" />
                <appender-ref ref="STDOUT" />
        </logger>

        <logger name="org.openhab" level="INFO"/>

        <!-- this class gives an irrelevant warning at startup -->
        <logger name="org.atmosphere.cpr.AtmosphereFramework" level="ERROR" />

        <!-- temporary workaround for https://github.com/openhab/jmdns/issues/12 -->
        <logger name="javax.jmdns" level="OFF"/>

        <!-- temporary workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=402750 -->
        <logger name="OSGi" level="OFF" />

        <!-- temporary workaround to circumvent error messages with any obvious effect -->
        <logger name="org.atmosphere.cpr.AtmosphereFramework" level="OFF" />
        <logger name="org.atmosphere.cpr.DefaultAnnotationProcessor" level="OFF" />
        <!--<logger name="org.openhab.binding.zwave" level="TRACE"/> -->
        <!--<logger name="org.openhab.io.transport.mqtt" level="TRACE"/> -->
        <logger name="org.eclipse.jetty.io.nio" level="ERROR"/>

        <root level="WARN">
                <appender-ref ref="FILE" />
                <appender-ref ref="STDOUT" />
        </root>

</configuration>

Note that I have some customization commented out for debugging some of the bindings.

And logback_debug.xml

<configuration scan="true">

        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
                <encoder>
                        <pattern>%d{HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}:%-5line] - %msg%n</pattern>
                </encoder>
        </appender>

        <appender name="FILE" class="ch.qos.logback.core.FileAppender">
                <file>${openhab.logdir:-logs}/openhab.log</file>
                <encoder>
                        <pattern>%d{HH:mm:ss.SSS} [%-5level] [%-30.30logger{36}:%-5line] - %msg%n</pattern>
                </encoder>
        </appender>

        <appender name="EVENTFILE"
                class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>${openhab.logdir:-logs}/events.log</file>
                <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
                        <!-- weekly rollover and archiving -->
                        <fileNamePattern>events-%d{yyyy-ww}.log.zip</fileNamePattern>

                        <!-- maximum number of archive files to keep -->
                        <maxHistory>30</maxHistory>
                </rollingPolicy>
                <encoder>
                        <pattern>%d{yyyy-MM-dd HH:mm:ss} - %msg%n</pattern>
                </encoder>
        </appender>

        <logger name="runtime.busevents" level="INFO" additivity="false">
                <appender-ref ref="EVENTFILE" />
                <appender-ref ref="STDOUT" />
        </logger>

        <logger name="org.openhab" level="DEBUG" />
        <logger name="org.openhab.binding.knx" level="DEBUG" />
        <logger name="org.openhab.binding.onewire" level="INFO" />
        <logger name="org.openhab.ui" level="INFO" />
        <logger name="org.openhab.ui.webapp" level="DEBUG" />
        <logger name="org.openhab.ui.webapp.internal.servlet" level="INFO" />
        <logger name="org.openhab.io.net" level="INFO" />
        <logger name="org.openhab.core.autoupdate" level="DEBUG" />
        <logger name="org.openhab.core.persistence.internal" level="TRACE" />
        <logger name="org.openhab.core.transform.internal.service.MapTransformationService" level="INFO" />
        <logger name="org.openhab.binding.vdr" level="DEBUG" />
        <logger name="org.openhab.model.core.internal.folder" level="INFO" />
        <logger name="org.openhab.io.dropbox" level="DEBUG" />

        <logger name="OSGi" level="WARN" />
        <logger name="org.eclipse.jetty" level="WARN" />

        <logger name="org.openhab.io.dropbox" level="DEBUG" />

        <!-- temporary workaround for https://github.com/openhab/jupnp/issues/9 -->
    <logger name="javax.jmdns.impl.DNSIncoming" level="ERROR"/>

        <!-- temporary workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=402750 -->
        <logger name="OSGi" level="OFF" />

        <logger name="tuwien.auto.calimero" level="WARN" />

        <root level="INFO">
                <appender-ref ref="FILE" />
                <appender-ref ref="STDOUT" />
        </root>

</configuration>

seems exactly the same as the one I had in there, minus the configurations I had made. I guess I’ll add one back to /etc/openhab/ AND /etc/openhab/configurations but I’m not optimistic it will work. I also am not sure why apt-get isn’t installing one at all, though I now feel better about not backing up the default copy before overwriting it, I’m pretty sure it was never there…

That is weird and if you see it reliably not install logback.xml you should raise an issue on github.

ok, not sure exactly how to do that, but it’s def not installing. I’ll look into it I suppose.

Perhaps I’m missing something but I grepped /etc/init.d/openhab for openhab.sh and it wasn’t in there. openhab.in.sh was, but not openhab.sh. I would’ve thought the init script should need to call that shell script at start. However even when running the shell script without init, i get a bunch of action in the console, but the webui still doesn’t show up at the specified port.

The openhab script in init.d doesn’t just blindly call the openhab.sh script. First is imports the contents of openhab.in.sh which itself imports /etc/default/openhab into itself (if you look at openhab.in.sh you will see it do that and that it also defines a whole bunch of variables). Then based on all of those defined variables it builds the command to execute openHAB itself instead of calling openhab.sh.

So, now that I’ve gone down the rabbit hole, I find that changing the HTTP/HTTPS ports in openhab.sh will not change it when OH is run as a service. You need to change it in /etc/default/openhab.

This really needs to be updated on the wiki. If this works for you can you do it?

Are you still seeing the binding error when starting OH, either with the script or as a service?

haha that makes sense!! Because I DON’T have a file at /etc/default/openhab. One was never created and I never made one. What exactly am I putting in there? In the Configuring the openHAB runtime wiki under the “advanced settings” section, this is what it lists:

You will find the openHAB configuration under /etc/openhab. If you change configuration files it will not be overwritten by updates or upgrades.

${openhab_home}/etc/default/openhab

USER_AND_GROUP=openhab:openhab
HTTP_PORT=8080
HTTPS_PORT=8443
TELNET_PORT=5555
OPENHAB_JAVA=/usr/bin/java

The part i find confusing, that I asked about earlier, is the variable ${openhab_home} in the file path above. Does that mean i need to create a file in /etc/openhab/etc/default/openhab, /usr/share/openhab/etc/default, or just plain old /etc/default/openhab. Assuming the latter option, my expected workflow:

  1. sudo touch /etc/default/openhab
  2. sudo nano /etc/default/openhab
  3. enter in the above desired port numbers
  4. sudo chmod openhab:openhab /etc/default/openhab
  5. reboot

That seem right?

And is that wiki article i linked to above what you want me to update if this works? Or this Linux one? or both? never updated a wiki before, but am happy to contribute, just don’t want to make it worse

Those instructions seem to be written for manual installed openHABs. There is no openhab_home with apt_get installs so the file should just be in /etc/default.

For the contents of the file use the following (these are unchanged from my install) and change the ports as necessary:

# Execution account and group. The user account should be member of group
# "openhab" if it's different than "root" and "openhab".
# Note that some bindings may require "root" access to the system.
# Default value if isn't specified - "root:root".
USER_AND_GROUP=openhab:openhab

# Web server's listening ports (plain and SSL). Note that if execution account
# is different than "root" the port numbers should be greater than 1024.
# Default value if isn't specified - none, must be specified.
HTTP_PORT=8080
HTTPS_PORT=8443

# Console's listening port, same restriction as this for web server's ports.
# Default value if isn't specified - none, must be specified.
TELNET_PORT=5555

# Extra arguments passed to Java
JAVA_ARGS=

# Extra arguments passed to openHAB
OPENHAB_ARGS=

# Use non-default Java VM.
# Default value if isn't specified - system default Java VM.
#OPENHAB_JAVA=/usr/bin/java

# To enable debugging set to "yes" (case insensitive).
# Default value if isn't specified - debugging is disabled.
DEBUG=no

For step 5 you don’t need to reboot the machine, just restart openHAB with
sudo service openhab restart

The wiki article you lined to above which is supposed to have the instructions for how to change the port numbers.

Sorry for the delay, real life got in the way of what was important :slight_smile:

I really thought that was gonna work but it hasn’t yet gotten something to show up in my browser at the specified port. I touched /etc/default/openhab and pasted in what you wrote and started the service. Below is the last time I queried the status of the service :
sudo systemctl status openhab.service
● openhab.service - LSB: openHAB server
Loaded: loaded (/etc/init.d/openhab)
Active: active (running) since Wed 2016-03-02 22:49:17 CST; 8min ago
Process: 1870 ExecStop=/etc/init.d/openhab stop (code=exited, status=0/SUCCESS)
Process: 1891 ExecStart=/etc/init.d/openhab start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/openhab.service
└─2119 /usr/bin/java -Dlogback.configurationFile=/etc/openhab/logback.xml -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShu…

Mar 02 22:49:17 HOMi openhab[1891]: Starting openHAB server: openhabchown: cannot access ‘/etc/openhab/jetty/etc/keystore’: No such … directory
Mar 02 22:49:17 HOMi openhab[1891]: chmod: cannot access ‘/etc/openhab/jetty/etc/keystore’: No such file or directory
Mar 02 22:49:17 HOMi openhab[1891]: chown: cannot access ‘/etc/openhab/configurations/users.cfg’: No such file or directory
Mar 02 22:49:17 HOMi openhab[1891]: chmod: cannot access ‘/etc/openhab/configurations/users.cfg’: No such file or directory
Mar 02 22:49:17 HOMi openhab[1891]: .
Mar 02 22:49:17 HOMi systemd[1]: Started LSB: openHAB server.
Hint: Some lines were ellipsized, use -l to show in full.

Because of those chmod and chown errors I decided to try to run the setpermissions.sh file in /usr/share/openhab/bin and much to my chagrin it was just returned a giant list of operation not permitted lines like these:

chown: changing ownership of ‘/var/lib/openhab/workspace/.metadata/.plugins’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/.metadata/.bak_0.log’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/.metadata/.log’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/.metadata’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/org.eclipse.equinox.app/.manager/.fileTableLock’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/org.eclipse.equinox.app/.manager/.tmp3723178031449267019.instance’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/org.eclipse.equinox.app/.manager’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/org.eclipse.equinox.app’: Operation not permitted
chown: changing ownership of ‘/var/lib/openhab/workspace/org.eclipse.core.runtime/.manager/.fileTableLock’: Operation not permitted

Is there something wrong with my openhab user? In /etc/passwd this is what is present:
openhab:x:110:116:openHAB runtime user,,,:/var/lib/openhab:/bin/false
That seems fine no? I also added openhab as a sudoer with sudo visudo…

Sometimes I miss things, particularly on these long threads when I read and respond from my phone.

Have we established whether you are trying to get OH 1 or OH 2 up and running?

Everything I have suggested this far, locations of files, etc are all for OH 1, not OH 2.

OpenHAB 1.8.1 is what I’m attempting to get up and running AFTER having OpenHAB 1.8.0 running under my own username.

edit: added the word “after” without which my reply was entirely nonsensical.

I gave my openhab user bash abilities. Or at least I think i did by changing the approprate line in /etc/passwd to
openhab:x:110:116:openHAB runtimeuser,,,:/var/lib/openhab:bin/bash

Alas, after a reboot it did not help.

I really have no idea what state your system is in right now. Files that should be places are not there. And not having the system in front of me I am only guessing at best right now.

If it were me, I would completely start from scratch from the OS on up. Clearly the apt-get installation did not work correctly and I know of no what to make it work correctly short of starting over.

While I appreciate that stance (and your opinion) and have more or less come to terms with this as an option, since I spend hours at a time just trying to figure out WHERE I can look to just get some kind of informative log, still I’d really appreciate NOT going to the nuclear option just yet. I have a bunch of other things on this pi working great, and I REALLY think there’s a clue in the errors I’m receiving when I try to run setpermissions.sh. I saw your github issue here. Doesn’ that seem related at all? Getting chown/chmod “operation not permitted” errors HAS to be something to do with my openhab user, right? You say something in there about creating the openhab user BEFORE installing the script or not? was this an issue? Why wouldn’t chmod operations be permitted? It HAS to be related to permissions right?

When an apt-get install works properly an openhab user and group is automatically created for you (if it doesn’t already exist), default config files are placed in the various directories that they need to be placed in (if they don’t exist) and those files are chown’d to openhab:openhab. The program is also configured to start as a service running under the openhab user.

You are missing files and those files that do exist do not have the right permissions. Therefore the apt-get install failed and failed hard. Furthermore, we tried to do a forced reinstall of openHAB through apt-get and you are still missing files and still having permission problems. Something is fundamentally, inexplicable, and drastically wrong with your system that is causing apt-get to fail.

I believe that if you had someone like kai, teichsta, or watou sitting at your machine they could probably figure out what went wrong and how to fix it but I have no confidence that you or I will be able to solve the problems at this point with you being new to OH and I not sitting at your system (not to mention I’m not one of the developers so don’t really know where to look).

Personally I would take this opportunity to figure out how to automate the configuration and deployment of what you have running on the Raspberry Pi and build up the system from scratch.

In answer to your specific questions:

Not really. If the apt-get install worked correctly everything should have the correct ownership and permissions. The issue I have in github is that additional files that I add to openhab directories (e.g. ssh keys to ~openhab) have their permissions automatically changed by the setpermissions.sh script when OH starts which breaks my exec scripts which ssh to another machine. The issue does not cause any problems with OH itself. If you are seeing setpermission.sh errors it is because the files do not have the correct ownership or permissions to allow the openhab user to change them.

It does but that is a symptom of your problems, not the root cause of your problems. I have no confidence at this point that finding and changing the permissions of the files generating the errors will result in a working OH server.

That was actually watou and it was an issue similar to what I had. Watou has some additional files in ~openhab and the setpermissions.sh script was blindly changing the permissions on all files in ~openhab, even those which need different permissions like those in ~openhab/.ssh or executable scripts.

Because either the files it is trying to change do not exist or they are owned by someone other than the openhab user. In either case it means a severely broken installation.

OK, I understand and am with you for the most part, at least until here. Granted there are 2 files that don’t exist, the users.cfg and ssh, but all the others, specifically for sure the ones that I wrote down DO exist AND are owned by openhab:openhab. And that’s where I feel like there is something small but fundamentally wrong with the USER. Afterall, those files being owned by another user shouldn’t be an issue for chown right? Since that’s what it’s supposed to do, change ownership?

Somewhere in one of the folders listed in /usr/share/openhab/bin/openhab.in.sh there are files that are not owned by openhab.

If the files are owned by someone other than openhab and permissions are such that openhab is not allowed to write to those files then chown will fail. Only root is allowed to change the ownership of a file that it doesn’t explicelt have write permissions to and the setpermissions.sh script runs as openhab.

Ok, that makes sense, but if setpermissions.sh runs as openhab what exactly is it expecting to be able to change? Wouldn’t it only have the ability to change something that’s already owned by openhab and thus not really change anything at all?

It chowns AND chmods and I think the main point is the chmod part.