Telemetry does not show up in Thingsboard device dialog ("Hello world" tutorial) - thingsboard

I installed ThingsBoard CE on premises. I followed
https://thingsboard.io/docs/user-guide/install/ubuntu/
step by step. Installation base is a fresh Ubuntu 22.04 Server install on a virtual host with no other duties. It's an IPv6-only installation with 127.0.0.1 being the only IPv4 address reachable direcly, other IPv4 targets by NAT64/DNS64. From what I see (e.g. by systemctl), all services (Postgresql, Zookeeper, Kafka, Thingsboard) boot up correctly. I installed Thingsboard with the --loadDemo option in step 6 of the instructions. I can log in using the preinstalled accounts. I've changed the passwords. After having checked that things work connecting to localhost:8080, I've installed Apache-based reverse proxies for IPv6 and IPv4 connectivity. This all works.
Next, I continued with the "Hello world" tutorial in
https://thingsboard.io/docs/getting-started-guides/helloworld/
I fire the mocked telemetry transmission using curl:
root#thingsboard:~# curl -v -X POST -d '{"temperature": "24"}' http://localhost:8080/api/v1/xxx/telemetry --header "Content-Type:application/json"
On HTTP level, this seems to work:
* Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> POST /api/v1/xxx/telemetry HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 21
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Content-Length: 0
< Date: Wed, 26 Oct 2022 04:33:32 GMT
<
* Connection #0 to host localhost left intact
I do not see, however, the telemetry data in the "Latest telemetry" tab of "My new device" in the tenant's "Devices" dialog. I tried
Sending the data remotely via the reverse proxy or directly to localhost:8080
Sending via IPv6 or IPv4
Replacing the Kafka queuing with in-memory queuing by disabling the Kafka-config lines in thingsboard.conf.
Nothing changed the behaviour a bit. However, making it syntactically incorrect JSON or using a wrong crendential lead to different error result codes so Thingsboard is actually processing the message.
I cannot see anything in the tenant's "Api usage" dialog either as there are only spinning wheels in subframes.
And that's where I am stuck at the moment. I don't have an idea where to look for the problem as I don't even know where I possibly could look.
Can anyone help me?
Best regards,
Dirk

To confirm that the telemetry has correctly reached the device that you have indicated in the post url (/api/v1/xxx/telemetry), you have to set up debug mode in rule chain nodes: https://thingsboard.io/docs/user-guide/rule-engine-2-0/overview/#debugging
All devices messages by default is going to root rule chain, set up debug mode in "Message Type Switch" node and send the same request again, then check events of that node.
If everything goes fine, the output of "Message Type Switch" must be "Post telemetry"
rule chain
"Save Timeseries" is the node that is responsible for saving telemetries.

As often, the problem was at a completely unexpected location: It turned out that ThingsBoard actually processed the events perfectly but my reverse proxy was misconfigured. This was also the reason for
I cannot see anything in the tenant's "Api usage" dialog either as there are only spinning wheels in subframes.
I use Apache as reverse proxy. It needs the proxy, proxy_html and proxy_wstunnel modules enabled and the following configuration (assuming it runs on the same machine as ThingsBoard):
# close off proxying while allowing reverseproxy
ProxyRequests Off
# pass header information through to the proxied host
ProxyPreserveHost On
# mod_proxy_wstunnel for the data websockets
ProxyPass /api/ws/ ws://localhost:8080/api/ws/
# "normal" http reverse proxy
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
Now I see the telemetry, I have the dashboards and I can finally continue following the tutorials.
May I suggest the the on-premises installation instructions at least mention this configuration need? It's a trivial pitfall but it can be really frustrating if you forget it and get no hint that there is a problem.

Related

can't open passbook passes when served through an nginx reverse proxy

My problem is that I can download passbook passes directly from my api, but with nginx as a reverse proxy in front of my api, safari can no longer open the pass.
I have a system with a ticket-service, an api and an nginx instance that operates as a reverse proxy.
I can request a ticket as a passbook pass file directly from the api through my ios simulator, but when I do the same with nginx between, ios safari returns: "Safari cannot download this file.".
I have tried to do the two requests through chrome on my laptop to check the headers and noticed that nginx adds two; Connection: keep-alive and Server: nginx.
I then tried to add those two to the api as well, just to check that safari don't complain about them and the headers then seem to be the same in chrome.
Headers
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Etag
Connection: keep-alive
Content-Disposition: attachment; filename="JABJcCu42k"
Content-Encoding: gzip
Content-Length: 72312
Content-Type: application/vnd.apple.pkpass
Pragma: no-cache
Server: nginx
Vary: Accept-Encoding
Date: Thu, 09 Jul 2015 10:01:31 GMT
Does anyone have experience or have an idea of what the problem might be?
Thanks!
BR Fredrik

AWS ELB keeps showing private IP in Location header on redirect

We are running a simple Rails 4.0 app (on Ubuntu 14.04) with config.force_ssl = true. SSL is uploaded to our ELB and both 443 and 80 ports on ELB forward to 80 on the servers.
We keep failing our PCI scan because with HTTP/1.0 the private IP of the ELB shows up in Location header. Any ides on how to fix this? I have researched this extensively for days and really stuck now.
$ telnet app.ourwebsite.com 80
GET / HTTP/1.0
HTTP/1.1 301 Moved Permanently
...
*Location: https://172.31.26.236/*
Server: nginx/1.6.2 + Phusion Passenger 4.0.57
Set-Cookie: AWSELB=...
The reason why it's failing PCI compliance is because the test being used, nessus plugin 10759, uses HTTP 1.0 and doesn't send a host header, and the AWS ELB crafts its own host header when it connects to your instance and for whatever reason sets it to the internal IP of the load balancer.
Here's a capture of such a request using Apache's mod_forensics. Note the host header, which is set to the internal IP of the load balancer:
+11143:551306af:1|GET / HTTP/1.1|host:10.3.2.57|X-Forwarded-For:REDACTED|X-Forwarded-Port:443|X-Forwarded-Proto:https|Connection:keep-alive
This is how the request was made (on *nix using bash):
(echo -ne "GET / HTTP/1.0\r\n\r\n"; sleep 2) | openssl s_client -connect 1.2.3.4:443
Where 1.2.3.4 is the IP address of your ELB. You must craft the request like this because the ELB won't accept \n\n directly typed into openssl.
Note that the only header sent here was GET.
My site was failing a PCI scan, which lead me here, so I felt this needed further explanation.
It sounds like your ELB is receiving https and then forwarding on http. So your Rails server doesn't need to worry about SSL, since the only thing it's communicating with is the ELB.
(This is how we have it set up also.)
So you can remove config.force_ssl = true from your Rails server and make your ELB require SSL.

Find out what web server a Rails app is working on on the hosting

I'm given access to a Rails application which is hosted on a Linux machine. I need to setup a redirection from www to the root domain and, although it can be done via the application using before_filter or route.rb, it's better to do it via the web server. But I don't know what web server it's working on. It may or may not be nginx - I don't know. This is what I need to find out. How can I do that?
Launch your browser.
Open the developer tools, go to the Network tab
Navigate to the web app.
On the left panel, click on any of the loaded resources.
Select the Headers tab and find the Server header within the Response headers section.
This screenshot was made with Chrome (it's slightly different with Firefox or IE)
You can run the following in command line:
curl -I www.yoururl.com
or
curl -I youripaddress
When I run this for my server I see:
HTTP/1.1 200 OK
Server: nginx
Date: Sat, 27 Dec 2014 02:20:01 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Status: 200 OK
This is a super quick way to find out! :)
Good luck!!

RabbitMQ 3.0.x issue with monitoring

I have used RabbitMQ 2.8.6 on Ubuntu 11.10 with success quite long time
and recently decided to upgrade it up to newest version (3.1.x).
I use the custom monitoring for RabbitMQ by using management plugin possibilities.
Unfortunately, on newest version this monitor didn't work by some unknown reason.
I have even tried to send simple request to check workability
curl -i -u guest:guest http://127.0.0.1:55672/api/overview
and get strange response
HTTP/1.1 301 Moved Permanently
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Location: http://localhost:15672/api/overview
Date: Sat, 11 May 2013 09:37:04 GMT
Content-Length: 0
instead of (as before)
HTTP/1.1 200 OK
Server: MochiWeb/1.1 WebMachine/1.9.0 (someone had painted it blue)
Date: Sat, 11 May 2013 09:54:49 GMT
Content-Type: application/json
Content-Length: 1659
Cache-Control: no-cache
{"management_version":"2.8.6","statistics_level":"fine",...
I noticed that MochiWeb server version is downgraded. Is it a RabbitMQ BUG or maybe my mistake?
Check the official docs here:
http://www.rabbitmq.com/blog/2012/11/19/breaking-things-with-rabbitmq-3-0/
The Management plugins now listens to 15672 and not 55672
Also, it is clear from the response that the page is permanently moved to http://localhost:15672/api/overview

MVC in IIS do not send scripts to client?

I have setup a MVC website in my own IIS7(Windows 7) but no files under the folder Scripts(that is in the root of website) is found? If I upload the solution to the webhost or runns it in VS mini IIS it works fine?
I have set this in the web.config :
<authorization>
<allow users="*"/>
</authorization>
I have given full access to the entire website folder(with subfolders/subfiles) to the following users : IIS_IUser, NETWOR SERVICES, IUSR.
The site is runned by the 4.0 application pool that runnes by the ApplicationPoolIdentity.
I have tried this url : localhost/Scripts/ but this will only return a 404 error.
When checking the explorer I can see that there is files?
Edit: Images and CSS do work but not Script folder and the content. I have dubblechecked the rights.
Didn't you by accident forget to install the Static feature of IIS? You can enable this when you open Control Panel > Programs > Turn Windows features on or off > Internet Information Services > World Wide Web Services > Common HTTP Features, there make sure the checkbox before Static Content is checked.
Screenshot:
I have got the same issue on a brand new Win 2k8 R2 server running asp.net.
Did you ever solve the problem?
using httpie if found that the headers were different for normal 404 and 404 errors on the Scripts folder:
HTTP/1.1 404 Not found
Content-Length: 0
Date: Wed, 19 Sep 2012 14:27:15 GMT
Server: Microsoft-HTTPAPI/2.0
Version: 11.0.11282.0
as opposed to
HTTP/1.1 404 Not Found
Cache-Control: private
Content-Length: 5222
Content-Type: text/html; charset=utf-8
Date: Wed, 19 Sep 2012 14:21:32 GMT
Server: Microsoft-IIS/7.5
for any other random folder.
Am currently investigating if it is SQL Server Reporting Services that is blocking it. ... appears not
searching on server version brings up QlikView forums ... that is installed on server, so investigating that now ... stopped QlikView and it fixed it.

Resources