I've been trying to connect Freeboard to visualize context information from OCB, however came across difficulties that prevent me from receiving any data from there. My thinking is that there is a problem with connecting Freeboard to OCB, because in OCB's subscription list there are no any new entries, and datasource in Freeboard shows that it has never been updated.
OCB is turned on as a docker container. Freeboards run in docker host.
I tried setting the ip as ip that I extracted from docker by:
sudo docker inspect --format '{{ .NetworkSettings.IPAddress }}' orion1
It gave me 172.17.0.3, but on that it didn't work either. I guess it shouldn't have anyways, because I can communicate with OCB by localhost:1026 as long as I do it via cUrl or Insomnia. I can push new entities, update and so on.
The accumulation server that has not been working (link here) is ok right now. But the thing is, I add subscription by myself and can't run the acc server on localhost (loopback interface), but rather on other avaliable interface, then add ip of that interface to subscription payload that i send to OCB. Maybe there is a conflict with Freeboard somewhere.
The issue here was connected to lack of CORS support. The easy solution for this is just enabling CORS functionality while launching Orion Context Broker as described here.
I have conducted quite an (actually unnecessary) research on this topic and came up with over-the-top solution for the problem which is described in this github post. There is a proxy server approach for solving the issue. I wanted to propose adding CORS support to Orion Context Broker, and was kindly surprised when found out about it being already implemented.
There are posts like this, this and this which was very helpful in solving the case.
However, I have a two requests. I guess #fgalan is a go to person right now, regarding back-end and documentation of OCB and peripheral software.
Can there be a stronger emphasis put on CORS and ACCESS-CONTROL-ALLOW-ORIGIN soulution? The reasoning behind it is that it gives a seamless connection between OCB and any front-endy application or site (i.e. Freeboard) running in internet Browser. It shouldn't be so hidden that I came across the solution for my problems just by accident while looking for something else. I guess putting it in some walkthrough documentation on I don't know some other visible place. The problem is that I spent two weeks trying to solve it and after all went for the over-the-top and unnecessary solution while the easy and accessible was just under my nose. Good thing is that I have a good connection on stack and git so it was resolved. There are probably people that gave up on Freeboard after any slip with it. And it's a shame, because for now there is no better opensource piece of software for visualization than Freeboard. And the problem is not only with Freeboard, as I said it concerns many more front-end applications and solutions. As we go with FIWARE's way of thinking, those things should be resolved differently.
The FIWARE datasource plugin for Freeboard is not worth a dime at the moment. As #fgalan pointed out in comment it was developed for v1 version of Orion Context Broker API and has not been updated. Therefore it's way more complicated than it's suppose to be. As documentation of OCB fairly point out, v1 approach is not really RESTfull like. After conducting a short code review of OCB plugin for Freeboard I can say that's not worth using. As far as I understand it should still be working, because OCB allows for v1 request to be conducted (but it doesn't work for me anyway), those request are deprecated. In my opinion new post regarding topic should appear (not sure who should I contact about it), because this is a bit misleading. What's the point of using piece of software that's deprecated and spreading bad habits regarding interacting with OCB?
Solution for this is in my opinion simple. Just use JSON datasource in Freeboard. I understand motivation behind creating individual datasource plugin for Freeboard in 2015, when there was not RESTfull v2 version of OCB API, but there is one now, so why not use it? I used ever since got rid of difficulties with CORS and it works pretty well in my opinion. Freeboard as I said earlier provides great opportunities while being easy in setup and maintenance. It should not be abandoned so easily.
By using GET request for JSON payload in Freeboard, now we have whole access to query for context from OCB. It doesn't need any POST methods as long as we use Freeboard as it supposed to be used (by querying for data to visualize). Throw in
?options=keyValues
to the request's URL and we've gotten ourselves a really smart and compact way of visualizing data coming from the Broker.
That's just the way I thing it should be resolved. Last update on this topic coming in 2015 is just not enough in my opinion, especially if there were better methods developed on accessing context data from OCB.
Related
We’ve created some kind of python monitoring app that performs health-check of our system once in 10 minutes and sends text alarms to our engineers (via jabber/slack) if something went wrong.
Are there any best practices we can introduce to be sure monitoring works even if server it’s hosted on is down? Any good books/online materials covering stability topic? First idea was to use docker swarm and multiple servers (just because I know it exists and seems to solve the problem) but maybe there’re way better solutions I’m not aware of.
I would say the best practice would be to build your SRE stack out of off the shelf rather than home grown components.
prometheus, alertmanager and so on.
Then you want your actual alerting infrastructure to be cloud hosted - PagerDuty for example.
And use something like Pingdom as an external check that your crucial infrastructure is operating.
I don't mean any offense, but as I was setting up my Octoprint, a skeptical colleague of mine pointed out that it wanted to reach out to check for automatic software updates, creating broad surface area for potential attackers.
After all, the RaspberryPi is a device inside my home network, and I worry what might happen if it downloaded and ran code designed to find other vulnerable devices on my network.
I suppose I could read the open source code, but I don't know what the software delivery story is.
Planning to donate to Gina Häußge's Patreon to ask directly.
You can turn off Octoprint's auto-update feature. It is also open-source, so you can modify its code to never contact the Internet.
Quoting Gina Häußge:
As with any software that you install on your machines, there are no guarantees that it can't be abused. OctoPrint's update mechanism utilizes Github Releases via HTTPS only, and I require anyone with commit access to the repository to have two factor authentication enabled. That should make it fairly unlikely to get any rogue releases pushed via the official update mechanism. You can also just deny OctoPrint access to the internet altogether, it will run just fine. Keep in mind though that you'll need to take care of updates and plugin installs and such manually then. Speaking of plugins, you should obviously also not install anything that you find somewhere on the net. I do my best to audit plugins that get registered on the official repository, but I cannot guarantee that their authors have 2FA and such enabled for their repositories... All I can tell you is, I do my best, spend a lot of thought on security and if push comes to shove you can always read the code yourself.
I have a MQTT environment like this:
there is One (gray) sensor and one Observer that are related by the topic room/temp, so far so good, sensor can publish and the Observer can get the info as it should.
the Issue I have is now: I need to block IN THE BROKER that a 2nd undesired client comes(the orange one),and start to publish into the same topic, as far as I know, MQTT is loose coupled so that observer doesn't care who is pushing the temp values, but I find a security flawless when someone hack my environment and publish non sense triggering my alarms...
any suggestion?
am using eMQTTd by the way and according to this there is nothing in the etc/emqttd.config file I can do to avoid that...
Thanks!
I only have experience with Mosquitto but, from a quick read of the document linked, it looks like there are several ways you could achieve this.
I am unclear if you are talking about an incidental problem here--i.e. bad information is being accidentally sent--or if you are protecting against an active threat.
If you are concerned with incidental overwriting of a value, then the simple clientid solution on (pg. 38) would work.
But my impression is that it would still be transmitted in the clear and thus be of little use to you if you are facing an actual adversary (hacker etc.). If that is your concern simply setup SSL and remove all non-SSL listeners. (See pg. 24). That should limit all traffic to an encrypted channel. Then if you wish add password / user authentication (pg. 38) to complete the security.
Alternatively, depending on your configuration, you could block unapproved ip addresses at the firewall level (i.e. block access to the port that your broker is listening on to all addresses except for the temperature sensor) or using eMQTTd's built in ACL facility (pg. 25). That would be less secure than a full SSL setup but depending upon your needs it might be enough.
Does anyone know of an elasticsearch client library for iOS? Would be a bonus if it was written in swift as well.
The elastic search 'clients' section shows multiple libraries for a number of platforms but nothing for iOS, I feel like someone must have done this?
Cheers
I doubt that anyone has - last time I checked there were none and for good reasons. Keep in mind that in order to allow an IOS client (or Android for that matter) to use a client library to connect to Elasticsearch you'd have to open up your cluster for either an http or node access - which would allow anyone to do anything to your cluster.
Maybe you could proxy it to prevent deletions and insertions but even so it would open up your cluster's data and open you up to DoS attacks.
Generally a better idea is to create your own REST API that incorporates some type of authentication and authorization and does not open up your cluster to the world.
If you still feel strongly about moving forward you can always just hit the http interface of the REST API for ES. Or take a look at this project someone was working on a few years ago at least to give you a head start:
https://github.com/tallpsmith/ElasticSearchIOSHead
Some recent discussions on this topic:
http://elasticsearch-users.115913.n3.nabble.com/Objective-C-client-for-ElasticSearch-iphone-ipad-etc-td3911216.html
Running Elasticsearch server on a mobile device (android / iphone / ios)
This may be what you're looking for. ElasticSwift. Seems to be in active development but haven't looked deep into how far they've gone.
This is another iOS Swift client that was made back in 2018: Appbase-Swift. It's a lightweight ElasticSearch/appbase.io client. Doesn't seem like it's been updated in awhile though.
We tried a lot for elastic and finally concluded that it on most of the challenging side. another thing is a bit bulky to use on mobile, as per my understanding no room for the optimization. We can only use HTTP Web Service call for the same service. Also, the flavor of the offline search can not be implemented in the mobile elastic till date...
Obviously there are multiple steps and phases of implementing such a thing.
I was thinking I would eventually have a webserver that takes http json requests from the ios app, and then queries the cassandra backend and sends results back. I could load balance and all that fancy stuff still, and also provide a logical layer on server side, and keep the client app lightweight.
I'm not sure i understand how cassandra clients fit though. It seems like the cassandra objective c client could eliminate the need for the above approach.
I saw another question and answer but it wasnt clear, perhaps because it varys on the need.
An iPhone app should not directly connect to a Cassandra backend or any other DB store.
First of all, talking to a database often requires adapting a very specific binary protocol (for Cassandra in particular, binary CQL or Thrift). Writing an adapter that would let your Objective-C app communicate in this binary protocol is a major piece of work, and could easily cost more than the rest of your app in effort. If you hide the DB behind a web-server, however, you will be able to select from a variety of existing adapters available in different server-side languages, meaning that you don't need to redo all that low-level work. You'll only be responsible for a relatively small piece of server-side code that would translate your REST queries and forward them to one of the Cassandra adapters (which expose easy-to-use interfaces).
Secondly, if you wanted to connect to a remote database from the phone, your database server would have to open its ports to the internet at large, which is a very bad security practice, even if you use SSL and user credentials. Again, if you hide behind a web server, you will be putting in a layer of technology that has evolved for decades to remain secure on the public internet.
Finally, having your phone talk to Cassandra directly is a poor architectural pattern. When you write apps that communicate on the internet, you want them to know as little as possible about each other, only how to talk to each other (preferably in a standard protocol). That way you can replace or upgrade individual components while keeping everything else the same. This may not sound like a lot, but is actually the main reason why phones, or web browsers, don't directly talk to databases. (If this setup were a good idea in principle, the first two problems could be easily solved given enough engineering effort.)
The approach you first suggested with JSON and the web server is the only correct way to go.
Use something like RESTful API, there are many reasons for that.
if your servers ip addresses change you have to update all client, if you add more nodes you will need to update all clients, if you decide to upgrade your cassandra and some functions change your clients will break and you need to update all clients.