OH3 restart BUNDLE from rule does no longer work

Add-ons Bindings
,
22

@Wolfgang_S
I like to reopen this thread … I moved to the milestone release OH 3.1 a few days back.
My rules to change log:levels do no longer work - I do not know if it is related to the 3.1 release. Any suggestion? thanks.

openhabian@openhabian:~ $ sudo /usr/bin/ssh -vvv -P 8101 -l /var/lib/openhab/.ssh/openhab.id_rsa openhab@localhost log:set DEBUG org.openhab.binding.zwave
OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 8101 is address
debug2: resolve_canonicalize: canonicalised address "8101" => "0.0.31.165"
debug2: ssh_connect_direct
debug1: Connecting to 0.0.31.165 [0.0.31.165] port 22.
debug1: connect to address 0.0.31.165 port 22: Connection timed out
ssh: connect to host 0.0.31.165 port 22: Connection timed out
23

The IP address doesn’t look like it is a real IP address.
That is most probably why it cannot connect and at the end times out.

24

The IP is derived from “localhost”, isn’t it?

25

No. localhost’s IP ‘normally’ look like 127.0.0.1, 127.0.0.2 etc.
I assume you do not mean localhost ( 127.0.0.0/24 ) but the IP of your OH host, right ?
According to https://www.ietf.org/rfc/rfc3330.txt IP networks that start with a 0 have special meaning and are only to be used as source address, not as destination address.

What is content of your /etc/hosts file ?

26

here it is …
the IP of my OH Server is different … 192.168.X.XXX

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1 openhabian

I think I found the reason for this error: I used a capital “P” in the command, it should be “p”.
But it is still not working. What I realized was that the console password for openhab was reset to habopen with the install of the OH3.1 Milestone. Can this now create an issue with the previously generated keys?

27

Based on the error message that you posted so far that cannot be concluded.
Do you still get the same error message that you posted earlier although you changed from upper -P to lower -p for the command parameter ?
In case everthing went well changing the password should not have any influcence on the used key.

But …
the home directory of the user may have changed from //openhab2 to //openhab where is just a placeholder for the root of the home directory of the user.
In case the sub dir .ssh is not copied / moved from openhab2 hoemdirectory to openhab the private key cannot be used.

Please also verify that you need to use -i and not -l
That is most probably one part of the root cause why the key is not used.

28

I did a test with the console access and this is what I got:

openhabian@openhabian:/etc $ sudo -u openhab ssh -vvv -p 8101 -i /var/lib/openhab/.ssh/openhab.id_rsa openhab@localhost
OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "localhost" port 8101
debug2: ssh_connect_direct
debug1: Connecting to localhost [::1] port 8101.
debug1: connect to address ::1 port 8101: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 8101.
debug1: Connection established.
debug1: identity file /var/lib/openhab/.ssh/openhab.id_rsa type 0
debug1: identity file /var/lib/openhab/.ssh/openhab.id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Raspbian-10+deb10u2+rpt1
debug1: Remote protocol version 2.0, remote software version APACHE-SSHD-2.5.1
debug1: no match: APACHE-SSHD-2.5.1
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to localhost:8101 as 'openhab'
debug3: put_host_port: [localhost]:8101
debug3: hostkeys_foreach: reading file "/var/lib/openhab/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /var/lib/openhab/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [localhost]:8101
debug3: order_hostkeyalgs: prefer hostkeyalgs: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512,hmac-sha2-256
debug2: MACs stoc: hmac-sha2-512,hmac-sha2-256
debug2: compression ctos: none,zlib,zlib@openssh.com
debug2: compression stoc: none,zlib,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: rsa-sha2-512
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug3: send packet: type 30
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:fal6VSYNaTnURYcraACNykcDlURq37u0LSOAUqFmQaA
debug3: put_host_port: [127.0.0.1]:8101
debug3: put_host_port: [localhost]:8101
debug3: hostkeys_foreach: reading file "/var/lib/openhab/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /var/lib/openhab/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from [localhost]:8101
debug1: Host '[localhost]:8101' is known and matches the RSA host key.
debug1: Found key in /var/lib/openhab/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 4294967296 blocks
debug1: Will attempt key: /var/lib/openhab/.ssh/openhab.id_rsa RSA SHA256*xxxxxxxxxx* explicit
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: keyboard-interactive,password,publickey
debug3: start over, passed a different list keyboard-interactive,password,publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /var/lib/openhab/.ssh/openhab.id_rsa RSA SHA256:*xxxxxxxxx* explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: keyboard-interactive,password,publickey
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug3: send packet: type 50
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: receive packet: type 60
debug2: input_userauth_info_req
Password authentication
debug2: input_userauth_info_req: num_prompts 1
Password:
29

That nearly looks ok.
To access the “remote” host/site the public key does not need to be imported into .ssh directory of user openhab but into /var/lib/openhab/etc/keys.properties.

E.g. add a row:

openhab=<your public key here>,_g_:admingroup
30

thanks. that did the trick.
I am absolutely positive that I had this entry in the keys.properties file before I moved from OH 3.0.1 to the OH 3.1 Milestone release. Does this file get overwritten with an openhab release-upgrade?

31

Debian .deb files contain a file that is named conffiles.
This file contains a list of configuration files that are not to be updated non interactively.
That means in case of an upgrade you should be asked what to do with such a file in case it is updated.
You have different possbilities on what to do in case of an upgrade.
Keep the edited file; use the file from the new release; interactively check what are the differences in the files. Normaly nothing gets lost in case you take the file from the new release a backup of the old edited one is kept.

32

Hello,

I am trying to restart a bundle in OH3, I found also some information to create a id.rsa file, but still if a try the following line in putty: ssh -i /var/lib/openhab/.ssh/openhab.id_rsa openhab@127.0.0.1 -p 8101 bundle:restart org.openhab.binding.homematic
I get still asked for the console password of habopen. So I am also not able to sent this command from an rule.
Is there an explanation available for an non linux specialist how to restart a Bundle from an rule?

Thanks, Peter

33

In case it is not a problem for you to put openhab’s password into a file you may try this ( Openhab-cli console +cron - #2 by Wolfgang_S ). Put the command into a shell script/file and call the file by running executeCommandLine.

In case you would like to run it using ssh public/private key pair: did you add the public key into openhab ssh configurationfile file which is: /var/lib/openhab/etc/keys.properties

34

Thanks,
I got it running by putting the command in a script file and run the script with executeCommandLine("/var/lib/openhab/HMrestart.sh"). Now I know how to sent the password in the script (-p was new for me)

Did you know why I can not put the command direct in the executeCommandLine like: executeCommandLine(“openhab-cli console -p habopen bundle:restart org.openhab.binding.homematic”)

In this case I get every time the following error: : error=2, No such file or directory

Is is not possile to use the command direct in the rule, is it really required to use a script file.

1 Like
35

executeCommandLine expects each single “word” to be separated from the next one by a comma.
Would mean: executeCommandLine("openhab-cli","console","-p","habopen","bundle:restart","org.openhab.binding.homematic”)

1 Like
36

Thanks,
now it is perfect working. Simple solution. No key required.

1 Like
37

How could this command sequence look like for a Windows10 installation of openHAB3 ?

38

as far as I can see the windows installation does not include the wrapper script openhab-cli.
openhab-cli is a wrapper for different use cases. In case of option console the client script is being called. In case of a windows installation it is called client.bat.

So you may try

executeCommandLine("client.bat","-p","habopen","bundle:restart","org.openhab.binding.homematic”)

This is untested as I do not have OH installed on windows.

39

Thank you very much for this valuable hint. Worked out for me like this in Windows10:

executeCommandLine(“C:\\openHAB3\\runtime\\bin\\client.bat”,“-p”,“habopen”,“bundle:restart 242”)

1 Like
40

After posting and being offline I remembered that I missed to add the path - but you found it !
I think it would be better to replace the number with the name of the related bundle. I am not sure if over time always the same number will be assigned. Besides that I would expect that “bundle:restart” and “242” have to be separated by a comma from each other.

41

This works out:
executeCommandLine(“C:\\openHAB3\\runtime\\bin\\client.bat”,“-p”,“habopen”,“bundle:restart 242”)

This does not work:
executeCommandLine(“C:\\openHAB3\\runtime\\bin\\client.bat”,“-p”,“habopen”,“bundle:restart","242”)